#1 On Being a Senior Engineer [Part 1]

Senior engineers should be mature engineers
- Seek out constructive criticism of their designs
- Understand the non-technical areas of how they are perceived
- Doesn’t matter how smart you are if no one wants to work with you
- Be the engineer everyone wants to work with
- Should still offer feedback on code - it doesn’t have feelings and shouldn’t be your baby
- Do not shy away from making estimates and try to get better at making them
- Have an innate sense of anticipation
* how long will this thing last before it needs to be rewritten? Is it readable? Am I making things easier?
not every project will be glamorous
lift the skills and expertise of others around them
* teaching to fish - requires patience and a perspective fo investment in the rest of the organization
Make trade-offs explicit when making judgements and decisions
* cannot be efficient and thorough at the same time - most projects exist on a n axis of optimality and brittleness - problems are either acute or chronic
* immature engineers discover tradeoffs in hindsight, mature engineers spell them out at the onset of a project, accept them and recognize them as a part of good engineering
don’t practise CYAE ("Cover Your Ass Engineering")
* don’t through people under the bus if your work doesn’t work
be empathetic
* recognize that all stakeholders goals are different
* see the project from other people’s perspective
don’t make empty complaints
* express judgements based on empirical evidence and bring options for dealing with them
* don’t go to your boss with a problem without at least one solution
* be aware of cognitive biases
* we are unaware of when we are interpreting things differently in our own brains in ways that defy empirical data
* self serving bias: if something is good, its because of something I did, if its bad, its someone else’s fault
* fundamental attribution error: the bad results someone else got are because of who he is (sloppy, stupid…), if I get a bad result, its because of my context/situation
* hindsight bias: tendency to view the past more simply than it was in reality
* outcome bias: it a damaging outcome, the decisions that came to that action are judged to be very stupid/reckless
* planning fallacy: being more optimistic about forecasting the time required for a project

#2 On Being a Senior Engineer [Part 2]

10 Commandments of Egoless Programming
1. Understand that you will make mistakes - you should just try to find them early
2. You are not your code - don’t take things personally
3. Know matter how much "Karate" you know, someone else will always know more - ask them to teach you some moves
4. Don’t rewrite code without consultation - know the difference between "fixing code" and "rewriting code"
5. Treat people who know less then you with respect, deference and patience
6. The only constant in the world is change, be open to it and accept it with a smile
7. The only true authority stems from knowledge, not from position - if you want respect in an egoless environment, cultivate knowledge
8. Fight for what you believe, but gracefully accept defeat
9. Don’t be the "coder in the corner" - this person has no voice in an open, collaborative environment
10. Critique code instead of people - be kind to the coder, not to the code - make all of your comments positive and oriented to the code (site local standards, program specs, increased performance, etc)

Novices Vs Experts
Novices are deeply subject to local rationality and adhere to rigid rules or plans
Experts are context driven and do not see problems as one thing and solutions as another, they act wholistically

Mature engineers know that how people feel (sometime irrationally) about technology is still important. People’s experiences with technology influence their opinions about it. Mature engineers understand this when making the case for using a specific technology as a solution.

Mature engineers hold the success of the project much higher than the potential praise they might get for working on it.

#3 Designing Accessible Navigations

Navigation also involves moving from section to section in addition to switching pages. To improve usability for everyone:

Allow users to skip content: include skip links (only visible when tabbed to) that allows users to bypass navigation
* important because otherwise users are forced to tab through all of the navigation every time they come to the page

Add an Accessibility Menu:
Reduces the amount of effort it takes for impaired users to access your content
an altogether different navigations to simplify an impaired individual’s experience
* Facebook provides dropdown that allow users to jump to different sections and includes a keyboard shortcut to access it anywhere

Consider Keyboard Shortcuts:
Offers users the opportunity to navigate the site and perform actions with one button - significantly reduces frustration
Lets users skip content they think is irrelevant
Show users a modal with all the possible shortcuts
Add hotkeys for the main pages in your app
* Have a goal for adding shortcuts and don’t just add them randomly

Properly Structure and Label Elements:
Apple’s VoiceOver supports Rotor which pops up a modal that shows the user all of your Headings, Articles, Links, Form Controls, Landmarks, and etc
Having all your sections have descriptive labels that can be used as landmarks and having proper type hierarchy allows users to confidently know what they are skipping

#4 Using Flow for Static Type Checking

Static type checking: types are known at compile time
Dynamic type checking: types aren’t known until runtime (javascript)

With a static type checker, bugs are caught earlier

Implicit Type Coercion: in JS we can reassign values to a variable that are not the same type - if it was a number, you can reassign it a boolean

Flow catches these types of errors.

Even though JS doesn’t check type, its always in the developers mind to reason about the code.

Why use Flow over TypeScript? Flow is easier to use, not a new language - just add /* @flow*/ to the top of a file.

#5 Designing for accessibility is not that hard

Myth: making a website accessible is difficult and expensive - fixing a site that is already inaccessible may require some effort though. Most problems aren’t hard to correct.

Why design for accessibility? Need to create a better experience for all users regardless of ability, context or situation, which usually results in a better experience for everyone.
* studies show that accessible websites have better SEO, a bigger audience, faster download times, encourage good coding practises, and have better usability
Seven easy things you can do:
1. Add enough colour contrast - contrast ratio needs to be at least 4.5 to 1 (conformance level AA) - use WEbAim colour contrast checker
2. Don’t use colour alone to make critical information understandable - use text or patterns
3. Design usable focus states - if you remove the browser focus state, you need to replace it
4. Use labels or instructions with form fields and inputs - don’t use just placeholder text! and don’t make the label disappear when they focus on the input
5. Write useful alternative text for your images and other non-text content - try to describe what’s happening in the image and how it matters to the story rather than just saying "picture". If you definitely don’t need alt text because the picture is redundant, adding an empty <alt> attribute will make screen readers skip it.
6. Use correct markup on your content - the components and structure of a page are what arranges an accessibility tree which powers screen readers
7. Support keyboard navigation - people who don’t have precise motor control (and power users!) rely on keyboards - pay attention to the tab order of elements - provide ARIA landmarks to make navigation easier