What is 1x.engineer ?

What is 1x.engineer ?

  • Searches Google, Duckduckgo, Bing, or wherever they like when they’re not sure what’s up.
  • Copy/pastes code snippets from Stack Overflow, Glitch, Codepen, or wherever they find answers.
  • Gives credit where credit is due.
  • Creates community and shares knowledge.
  • Spends time on things outside of engineering, like hobbies, friends, and family.
  • Has a schedule that allows them to maintain a healthy work-life balance, and respects others’ time-boundaries, too.
  • Isn’t measured by arbitrary contribution scores on any website, and doesn’t judge others for theirs either.
  • Writes code that has bugs.
  • Writes code that others can read.
  • Reads the Docs.
  • Updates the Docs.
  • Doesn’t need to be passionate about the code they write or the problems they solve, but may be.
  • Doesn’t act surprised when someone doesn’t know something.
  • Is willing and able to collaborate with others.
  • Publicly celebrates others for their wins.
  • Ask questions before providing critical feedback.
  • Gives tough feedback privately.
  • Treats others how they would like to be treated.
  • Provides code reviews and feedback to their peers that are constructive, helpful, and presented tactfully, helping their peers to grow personally and professionally.
  • Expresses appreciation for code reviews and feedback from their peers that are constructive and helpful.
  • Sometimes feels hurt by critical feedback, but doesn’t react destructively.
  • Sometimes takes short breaks to clear their head.
  • Makes mistakes from time to time, and finds growth in those mistakes.
  • Willing to admit when they’re wrong, and aren’t afraid to say “I don’t know.”
  • May or may not like writing documentation, but does it anyway for future maintainers.
  • May or may not like writing tests, but tries to learn to do so if the team or project needs it.
  • Thanks others for their time, effort, and energy.
  • Can have colorful desktop backgrounds.
  • Supports code in production, even if they did not write it.
  • Can feel like an imposter at times, and understands others may, too.
  • Believes that everyone in the room is equally as smart and capable as they are.
  • Will help level-up others, and asks for help when they need it.
  • Never stops learning, but can feel totally overwhelmed by the amount of learning there is to do.
  • Tries to keep discussions productive and lets others have their say before the team makes a decision.
  • Is willing to leave their comfort zone.
  • Contributes to the community in their own way when possible, and appreciates the ways that others contribute when they can.
  • Can be a slow coder.
  • Has productive and unproductive days.
  • Doesn’t take themselves too seriously.
  • Says, “I’ve never heard of that,” in lieu of nodding and pretending.
  • Is trustworthy.
  • Works to live, rather than living to work.
  • Sometimes loses their work.
  • Doesn’t have to have the entire codebase memorized.
  • Respects and upholds community Codes of Conduct.
  • May work from home, the office, a coffee shop, or where ever else best works for them.
  • Doesn’t hate on tools, processes, or languages that they’d rather not use, or that others are using.
  • Is not defined by the computer they’re using.
  • May decorate their laptop and workspace in any way they like, and is respectful of others’ decor (or lack thereof), too.
  • Isn’t defined by myopic Tweetstorms by clueless VCs.
  • Notice something missing from the list? 1x engineers are often humble and willing to accept Pull Requests to fix mistakes.
  • If you feel like you’ve got something that’s missing from the list, feel free to open a Pull Request against the website’s repo.

Joel’s Developer Test

Joel’s Developer Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

Rob Pike’s 5 Rules of Programming

Rob Pike’s 5 Rules of Programming


Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.

Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Pike’s rules 1 and 2 restate Tony Hoare’s famous maxim “Premature optimization is the root of all evil.” Ken Thompson rephrased Pike’s rules 3 and 4 as “When in doubt, use brute force.”.

Rules 3 and 4 are instances of the design philosophy KISS.

Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to “write stupid code that uses smart objects”.