
Rules of thumb for a 1x developer - ingve
https://muldoon.cloud/programming/2020/04/17/programming-rules-thumb.html
======
A21z
"Rule 11: Which database technology to choose: Choose SQL when you need to do
ad hoc queries and/or you need support for ACID and transactions. Otherwise
choose no-SQL"

I think it should be the contrary: SQL by default, no-SQL if you have a
specific need and know what you are doing.

~~~
tikiman163
To be completely frank, I'm seeing less and less reason to use traditional sql
databases. MongoDB offers the ability to make sql queries and even has Acid
transactions. Everything SQL can do, it does without slowing down when dealing
with big data. The only thing it doesn't offer an efficient solution for is
something SQL can't do either, and that's advanced search engine capabilities
like Elasticsearch provides.

Some people will argue that PostGreSQL is better in certain ways, but the
argument really always comes down to 2 factors. Are you going to hit the cost
efficiency performance limits of traditional SQL servers, and do you require
advanced searching capabilities like graph queries or synonym matching. Even
if both answers are No, I'd still argue for Mongo because it makes it easier
to distribute Acid compliant coppies of the data by region, providing backup
redundancy as well as fast responses in multiple regions.

~~~
OOPMan
Riiiiiiightttttttt, because having well defined data is not useful at all.

~~~
winrid
You can have well defined data and use Mongo. Those two things are not
related. I worked at a place that used Postgres and put an object w/ 11k
unique paths in a single JSONB column with no schema or documentation
whatsoever.

~~~
winrid
... and this system was responsible for billing, and many other things....

~~~
unnouinceput
and? That's not PGSQL fault, is the DB architect (or lack of) fault. You
definitely can drive the safest car in a ditch, no?

~~~
winrid
That was my point right? It has nothing to do with the DB.

------
cyrialize
I've been a developer for about 3 years now.

This is probably my own fault, but I feel pressured to be constantly doing
_something_ towards programming. I feel like I should either be reading a book
or starting a project.

I have 10+ programming books where I just finished reading one of them and I
have way more unfinished projects than I could count.

It's reassuring to see the push-back against the 10x developer idea, I'm
starting to feel less guilty now when I spend my free time NOT on programming.

Something that has also helped me out is picking a project to do, and ignoring
everyone else's projects. I would always get pulled away with what I'm
starting to work on because I see someone using a new technology or doing
something unique. When I would see that I would change up my project because I
felt it wasn't good enough or that it wouldn't make me a 10x developer. Now
I'm just trying to focus on what makes me happy and what I find enjoyable to
work on.

I want to ask though - the author works at Amazon and considers himself a 1x
developer. What does that mean for everyone else who doesn't work at Amazon or
a FAANG company? Is a 1x developer at a FAANG company a 10x developer
elsewhere?

~~~
Bahamut
A 1x developer at one of the tier 1 tech companies is...just a 1x developer -
doesn't really matter where you're at.

Being a multiplier is not about just being technically proficient. It's about
enabling your whole team to be more productive, and help getting to the right
decisions, instead of decisions that might cost your team or coworkers huge
amounts of extra work long term.

~~~
cyrialize
> Being a multiplier is not about just being technically proficient. It's
> about enabling your whole team to be more productive, and help getting to
> the right decisions, instead of decisions that might cost your team or
> coworkers huge amounts of extra work long term.

Thank you for this comment! I'll keep this in mind as I progress through my
career. It's nice to know that it isn't just about being technical.

------
cellularmitosis
"To replace out MediaWiki with a Java-based alternative (XWiki) ended up
taking a total fo 24 dev-years over 4+ calendar years for the team, not
counting the interruptions to pretty much every other team at Amazon as their
pages were getting constantly migrated and un-migrated"

I would _love_ to hear more about this. I'm guessing that's a cost of at least
$4M? How was this approved? How did they allow it to continue for _four
years_?

~~~
klohto
I don't understand why are corporations obsessed with decommissioning wikis.
When I was at Red Hat, they tried to decommission local country wiki in favor
of their company-wide wiki (Mojo, absolute shit by the way). They tried for
about 2 years, then finally somebody said "what the fuck are we doing" and the
migration was stopped. I believe the banner "Decommissioning soon" still hangs
there.

~~~
schnable
What happens is that different teams build out their own wikis , or come in
via acquisition). The company then ends up with a dozen of them, and re-orgs
occur and a single team now has two wikis, and people wonder why the
information isn't centralized. Everyone agrees it will be great to have a
singe company wide wiki and the project is born.

------
jordanpg
> That’s all that Agile means to me.

This is the most concise, honest summary of "agile" I've ever come across.
Well put.

The amount of person-hours spent bikeshedding about various sundry "agile"
procedural details is absolutely breathtaking. A perpetual, real-life Dilbert
punchline taken seriously by armies of *Managers.

~~~
engrsrce
Well that's pretty naive. I've worked with some pretty good teams that
wouldn't work any other way. I suspect you've only worked at places that
abused agile as described here... [https://ronjeffries.com/articles/language-
of-hatred/](https://ronjeffries.com/articles/language-of-hatred/)

~~~
jordanpg
No, I've worked in places where it works just fine.

The point is that, at the end of the day, it boils down elaborate processes to
break things up into two-week chunks of work. That's it. That's the bit I
thought was a concise, excellent summary.

Sometimes, for certain flavors of apps and tech and teams, that model works
splendidly. Sometimes, it is silly administrative window dressing that is
completely disconnected from the reality of what the team is doing. In my
experience, it's usually the latter -- and the teams work just fine _in spite_
of the fact that everyone is pretending they are doing "scrum" or "agile".

I'd say what is naive is the belief that such a closely scripted, narrowly
defined workflow is a one-sized-fits-all solution to optimizing teams under
all circumstances and contexts.

~~~
engrsrce
"Elaborate processes" and "closely scripted, narrowly defined workflow" aren't
adjectives I'd ever use for agile done well. And I've been doing it since we
were allowed to call it eXtreme Programming. There's lots of "Dark Scrum" out
there. Sounds like those are your experiences. They're not mine.

------
sufyanadam
> Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum
> can easily mean that you’ll get pressured to work extra hours to complete
> something within that arbitary two-week horizon.

This is very true. I've worked for over 12 years in the bay area in different
software engineering teams at startups and found that scrum just leads to
burnout and developer unhappiness and encourages team members to just do the
minimum 'slap it together till it works' solution without thinking long-term
on codebase stability, architecture and maintainability. By far the best
development process that leads to high developer happiness, engagement,
productivity and empowers them to go the extra mile to go above and beyond,
and produce work that acts as a force-multiplier across the team, is what the
author describes here as 'Kanban', also known as eXtreme programming. Most
people from Pivotal Labs or Carbon Five or from a startup that adopted their
process would recognize what the author describes as 'Kanban'.

~~~
eastbayjake
To be clear: XP and Kanban are different things. XP has prescribed engineering
practices, most forcefully that development should be done via pair
programming for continuous code review. Kanban prescribes no engineering
practices and could be used in lots of non-engineering contexts (e.g., your
marketing team could take all of their tasks, put them in a prioritized
backlog, then track the progression of those tasks across
Todo/Doing/Done/Blocked and that would still be Kanban). Kanban is great for
teams in maintenance mode with a steady in/out of smaller tasks in their
backlogs, but it's not great for helping your customers get an idea of when
they might see a new product or feature.

I do find it odd that people describe Scrum as "leading to burnout" or a
"death march", and I'm guessing most people who do either have not worked in
waterfall IT projects that preceded widespread Agile or they're part of
"Agile" teams that do waterfall development in two-week chunks with daily
standups. (Maybe both.)

Scrum practiced well brings the essence of small-town democracy into the
workplace. You have to work a late night the day before sprint release? You
were in the room when the team agreed to the body of work that would be
committed for delivery in this sprint. You just slapped it together until it
works? You'll get to accommodate 0-point bugs in a future sprint, and perhaps
you can have a conversation in your team's retrospective about why velocity
went down that week. (Speaking of: how many other professions get to have a
candid conversation with management about what's going well and not going well
on a regular basis? Not many, it's a real privilege!) There are certainly
deviations from this, but in my experience Scrum teams' problems are generally
of their own making, and many of those problems are refined away over time as
teams grow and better define their norms.

~~~
Aeolun
> You have to work a late night the day before sprint release? You were in the
> room when the team agreed to the body of work that would be committed for
> delivery in this sprint.

Fuck that. The fact that my estimate does not work out as expected should not
be a reason to work late nights just to get it done.

That’s exactly the death march that you were saying Scrum is not.

~~~
sufyanadam
+1 A million times on this, you nailed it.

------
aazaa
> And what I have found is that most – say, 90%, of what I learn at one job is
> completely useless for the next one.

Then the problem isn't with what's being learned. The problem is that the
author lacks a framework for generalizing and internalizing the lessons
learned.

Letting 90% of lessons learned on the job go to waste later in life is going
to lead to a very difficult career path.

Later...

> Compounding is a pretty important concept that shows up in compound
> interest, in Moore’s Law, all over the place. It’s about virtuous cycles.
> And so in the limited flexible time that I have, I think the rule of thumb
> is to focus on things that could trigger a virtuous cycle.

In other words, focus on activities that can capture more value from the 90%
of wasted lessons.

Writing, both publicly and privately, is an excellent way to do that. It seems
the author may have an inkling but isn't saying it. Given there are only two
posts on the blog, this could be the author's attempt to test the idea.

~~~
fnord77
> Writing, both publicly and privately, is an excellent way to do that.

Is there a right way to go about this? This is something I need to start
doing, personally.

~~~
Kwantuum
There are only wrong ways to go about it, and you will only discover them by
doing it.

------
imron
Rules of Thumb for a 1x Developer

During work hours stay away from:

* HN

* Facebook

* Twitter

* Reddit

* Any other thing constantly distracting you and taking away your attention from your job

Congratulations, you are now 3-10x developer.

~~~
war1025
> Congratulations, you are now 3-10x developer.

Congratulations. You are still getting paid the same.

Boosts in productivity need to come with boosts in pay, otherwise the logical
thing to do is to scale back your effort to a point where the amount you get
done matches the amount you get paid for.

~~~
nomel
I’ve never heard of a company that will offer to pay you more if you promise
to be more productive in the future. What industry are you in?

All of my raises and promotions came from results that exceeded expectations.

~~~
war1025
There is a balance though. The company I work for is stable, but money is
always tight. That means raises are few and far between.

Other factors balance that out and make it a reasonable place for me to work,
but being aware of the fact that "exceeds expectations" does not lead to more
money is important and I'm sure not unique to my situation.

I'm happy to go above and beyond, but I'm also aware that it's unlikely to be
rewarded and take that into account in my decisions.

------
overgard
With rule #2, (knowledge not transferring), that's always a sign you're not
working somewhere good, or you're in a role that will stunt your growth. You
really should be able to transfer a lot of what you learn. If you're stuck
with a bunch of proprietary gunk that does the same thing as open source, but
worse, good engineering management knows to replace that stuff because it will
inevitably drive talent away. Or at the very least rotate people through those
roles. I know I've left jobs where I've been stuck maintaining legacy systems
while the rest of the company moved on to open standards because if you do
that for years it's like slow career suicide.

------
stefanchrobot
Quite surprising take on the languages.

> When to use Python or Ruby

> Python and Ruby seem to me to be pretty similar in that they’re scripting
> languages and dynamically typed and seemed like the greatest thing in the
> 00’s. You use them when speed is more important than legibility or
> debugging.

I'd say you pick them when productivity and time to market is important. I
personally find dynamic languages far more legible (unless you're doing
metaprogramming-heavy stuff).

> Haskell or Erlang maybe I would use if I were doing something that required
> a very elegant or mathematical functional approach without a lot of business
> logic.

I think it's a mistake to throw these two into the same bag. I'd say Haskell
is functional and comes from academia. Erlang is concurrent (with functional
aspects) and comes from engineering background. You'd want to pick Erlang if
you want to build scalable backend systems.

> my guidelines for JS are:

> Try to push as much logic as possible to the server. If the front end
> weren’t super complex, I would consider something like Phoenix instead which
> actually pushes everything to the server.

Phoenix is a web framework for Elixir and Elixir is a Ruby-like syntax on top
of the amazing Erlang VM, so this kind of contradicts the suggestion above.
Either way, Phoenix LiveView might be a game changer when it's applicable and
for people who don't find the whole JS thing very exciting.

~~~
faizshah
People overrate the elegance and readability of languages. You can write
elegant and inelegant Java. I've seen python code that is totally
unmaintainable and python code that's some of the most elegant out there. You
can find Rails code that is some of the most indecipherable spaghetti out
there despite Ruby being such an elegant language (the project had Fat
Controllers, Fat Views and Fat Stored Procedures...yikes). There's a lot of
elegant C code out there then there's C code where you don't wanna touch
anything because you're not sure what anything does.

I think the general rule of thumb for languages is pick whichever language has
the best community, learning resources and packages for your project.

For example R excels at analyzing data because of the wealth of packages from
industry and academia for analyzing data and the tutorials dedicated to
statistical analysis in R. Python excels at high performance data driven
products because of the wealth of packages for ML, scientific computing, etc
and the wealth of resources on doing these things in python.

The exception to this is JS and your point about Phoenix LiveView. Potentially
it could be better to pick a single language for frontend and backend to limit
context switching while developing frontend and backend.

I haven't used Clojure or Haskell yet so I don't know what they excel at. I
also haven't dived into Erlang and Go enough to know which situations either
is better for scalable backends.

~~~
keithwhor
> People overrate the elegance and readability of languages.

> The exception to this is JS

JavaScript is beautiful. You're crazy.

~~~
faizshah
I think I was unclear. I meant that the exception to picking a language based
on community, resources and modules are JS and Phoenix Liveview where there is
an additional benefit of using a single language for frontend and backend. In
these two examples you might forego using a separate language for frontend and
backend (that could have a better community, resources or modules for what you
are building) because you can use the same language for both (which offers the
unique advantage of having to use and learn less tools for a fullstack app).

------
whateveracct
If you are a 10x developer, you should either angle to get 10x the money or
dial it down for your own benefit. Don't let some company get free value out
of you!

------
bearjaws
I hate the notion of "10x developer".

It focuses on hiring the best person, rather than firing individuals who
undermine the team. The reality is, there are some 1x developers, and some .5x
developers. Even worse though are the -1x developers. So many times I see a
corporate culture of firing = bad, so lets just try to find someone who is a
"10x", when really all you need is to remove the people who cause more work
for the organization.

Its our job as managers to accept that we hired someone who is ineffective,
damaging the team and that OUR hiring process failed to catch that. Then to
deal with them (training, firing) and iterate on the hiring process to prevent
the issue going forward.

~~~
ses1984
I knew two 10x developers at my previous job. One of them was humble and a
great mentor and elevated everyone around him. One was a grump who made
everyone around him feel stupid.

Imo toxicity is independent from productivity.

~~~
justaguyhere
Same experience. I learned quite a bit simply by sitting next to an
exceptionally good and exceptionally nice developer who was at least a decade
older than the rest of the team and enjoyed helping others. He rarely got
stressed even in crunch times and that put rest of the team at ease.

~~~
abyssin
The simple idea of this being possible, and picturing the scene in my head,
gave me a lot of hope. I'm tired of the atmosphere of fear in the office, and
I'm tired of how I participate in it.

------
nsfyn55
I don't think the author is a 1x programmer. He has learned the first secret
of 10x programming. It's not about being a genius programmer. Its about being
an efficiency expert and a problem solver. Soft skills play an outsized role
here. I have seen immensely talented developers with hard skills for days
manage to deliver nothing over long periods of time.

Learning that rules are guidelines not religious artifacts handed to us via
burning bush is a big step. I can't tell you how many programmers I've seen
hobble their own productivity by having overly aggressive code reviews, strict
style guidelines, or requiring more testing than is necessary.

Being an outstanding software engineer is 99% knowing when to tenaciously
stand your ground("storing state that way will not allow us to scale
horizontally. It will save us a few hours now but in order to achieve our
larger objectives will take 1000x the effort to unwind; we have to find
another way") and when exerting control isn't helping("You can't put this
simple, but incredibly important, time sensitive piece of software into
production until it has been reviewed by our 6 committees, is re-written to
use the companies globally enforced, yet questionably valuable style
guideline, and has 113% code coverage")

~~~
goalieca
He's working at amazon so perhaps their talent pool is a little better than
the average non-coastal company.

------
pjc50
This is cynical in a well-written way that matches my prejudices. I like it.

~~~
paulcole
Didn’t realize that it was already time for the annual HN slogan contest.

~~~
altonzheng
Almost spit out my coffee.

------
wirrbel
This document provides, especially towards the end, some valuable opinions.
The technology-advice is really bland or maybe overfitted to specific use
cases.

~~~
baylessj
Agreed. The general advice here is really useful. I am not clear on the
benefit of the discussion on programming languages and specific tech though,
that section seemed like an out of place admission of a lack of knowledge in
an article that contained many useful tips.

------
noad
I used to get called a 10x developer, I was also called a rockstar and a ninja
and a 100x dev and every other compliment that was hip.

Then I hit 30. That type of talk stopped.

Then I hit 40. Now I will not be considered for any entry level, mid level, or
senior level software dev job anywhere in the United States, despite being
very desperate and willing to relocate for anything. Doesn't matter. Too old.
I'm supposed to be doing something else by now.

Make a backup plan now.

~~~
dleslie
I am almost 40, and I fully expect this to be my last software development
job. Likewise, I've never had a negative performance review and am usually the
top task-killer and bug-destroyer; but when recruiters call and find out I'm
married with kids they can't seem to hang up fast enough.

I'm saving as much as I can. The end is nigh.

~~~
swader999
I don't understand why marriage or dependants would come up. If anything these
two life changes forced me to take my career and profession a lot more
seriously.

~~~
dleslie
Any number of ways:

\- What are your hobbies?

\- What drives you?

\- Where do you see yourself in five years?

\- Would you be willing to work long hours often?

\- Can you work in the USA?

And so on.

There's so many questions that are legal to ask but for which an honest answer
would reveal private information.

------
codesections
I was _very_ surprised to read

> 90%, of what I learn at one job is completely useless for the next one.

That has not been my experience at all (and I've had some pretty major job
changes, including lawyer -> software developmer). If I had to put a number on
it, I'd say more like 50% of what I've learned at each job is transferable.

How about everyone else? Closer to 10% or 50%?

~~~
jerf
I think there's a point of view component.

If you think of it is "Today I learned how to use $PROPRIETARY_AMAZON_TOOL to
set up a new project which will use $PAT to deploy to a
$PROPRIETARY_AMAZON_INTERNAL_CLOUD and sets everything up to $PA_MONITORING
and $PA_ALERTING in my... etc. etc. etc., you get the idea, then yes, you will
feel like what you "learned" is not transferrable.

On the other hand, if you look at it like "Today I learned some best practices
for setting up a new industrial-strength projects through the particular
manifestation of this tool, learned about setting up monitoring through the
particular manifestation of this other tool,", etc. etc., then even though you
may have learned via particular local tools, you also learned a lot of stuff
that may be useful later.

The question is, let's say you did change jobs and had to learn some new set
of tools. Will you learn them faster than you learned the first set of tools?
Will you find a new perspective on the issues from learning the new set of
tools? The answer should generally be yes. This is broadly speaking why I
expect a 5-year veteran to pick things up faster than a fresh grad; OK, sure,
you've never "used git", but I expect you've used source control somewhere.
You may not "know React", but I expect you to have used something similar
enough that you just have to learn React _qua_ React and are not also learning
about cookies and the basics of the DOM, etc.

Pretty much the first professional thing I ever did was writing what we would
today call a "static site generator" in a tool called Frontier, in its custom
programming language, more or less from scratch. On the one hand, completely
useless skill, Frontier has been dead for over a decade and was fairly zombie-
ish for a good 5-8 years before that. On the other hand... the HTML basics I
learned are still mostly good (I think it's fair to say at this point my
frameset tricks & skills are not that useful anymore...), and the general
skill of knowing how to write a static site generator is almost even low-level
_trendy_ right now, even though I would have to write it in some other
language, of course.

I dunno what the exact transfer number is. 90% seems high, certainly, but 10%
way too low. There's only a small number of tools that are so bad that while
working with them, you learn almost nothing about the problem space you are
working in because the quirks of the tool completely dominate, and even then
I'd submit a lot of it is still attitude.

------
vsareto
>One great example of this is the debacle of the Amazon internal wiki
migration. Back in 2015, the Amazon InfoSec team banned PHP at the company.

Oof. To be fair, Java is probably way easier to code review.

~~~
Filligree
Much depends on the Java. Having spent a lot of time on personal projects
using the language, it doesn't deserve its reputation -- Java may 'require' an
IDE to avoid spending too much time on boilerplate, but modern Java is a good
language and the programming experience once you do have that IDE is one of
the best, most effective I know.

At the same time, it's absolutely possible for codebases to become
"enterprisey" to the point where even the tiniest change takes weeks. Some of
the libraries out there use absolutely horrifying patterns.

If you're just coding for yourself, you can avoid those. In a company maybe
not so much, and even though the company would be better off avoiding them,
maybe they have old code remaining from when such things were considered
_good_.

~~~
The_Colonel
People really, really overrate the importance of a language. Java as a
language is quite decent, but definitely not great.

What makes it great is everything around it - from second to none JVM, range
of state-of-the-art developer tools to the best library ecosystem.

------
ken
> most – say, 90%, of what I learn at one job is completely useless for the
> next one

This is the most surprising claim, to me. I would have flipped the ratios.
Even the most radically different jobs I've had shared more than 10%.

90% of the _facts_ that my boss tells me are useless for the next job, true,
but 90% of what I _learn_ are not the facts which are told to me.

------
troelsSteegin
My takeaway from this: 1) don't overthink a problem 2) observe norms 3) meet
expectations. In other words, simply be reliable.

------
Traster
>Internal deadline: This is a target internal to the team that will not affect
anybody outside of the team.

Never in my life have I witnessed an internal deadline. If it came out of your
mouth and someone heard it, well done, you've got yourself a soft-deadline. If
you haven't said it out loud, it's an expected completion date, not a
deadline.

------
qwerty456127
> I think of Go, Rust, Haskell, Erlang, Clojure, Kotlin, Scala as more
> hardcore languages.

I can tell about Scala: it can be insane hardcore if you want, but it can also
be just "a much better Java" as easily - the weird parts are easy to avoid and
the normal parts work better. Unless you are a Java veteran and also plan to
hire more developers, using Scala instead of Java will save you much time and
effort.

And Kotlin is, by design, kind of Scala minus the hardcore.

~~~
solidasparagus
The problem with Scala is the same as the problem with Lisp. It's too flexible
and it ends up having a bunch of dialects. Sure you can only use a subset, but
that doesn't fix the problem that the fragmentation makes it hard to find
libraries and code examples that only use the subset of Scala you're
comfortable with.

------
deweller
> PHP is banned at Amazon due to security reasons, but its successor, Hack,
> runs a lot of..

Just to be clear, Hack is not PHP's successor. Hack is a fork of PHP developed
by Facebook. Hack will not overtake PHP any time soon.

PHP has had security issues in the past. Sure you can do stupid things with it
if you want, but modern PHP is security conscious out of the box. Frameworks
like Laravel make great default choices about security concerns.

~~~
kumarvvr
A small question. Is PHP still a preferred platform for any sort of complex
web development?

I have never even looked at the php site or docs, but I am curious.

In this day and age, is there a subset of Apps that PHP is suited for?

~~~
The_Colonel
Traditional (non-SPA) web apps is where PHP is quite strong.

Also depends on the team, if you have a PHP team and it's a web project, you
probably want to use PHP.

~~~
bzzzt
That's the problem right? Nobody starts new non-SPA web app projects anymore.

~~~
kumarvvr
There are many new projects that involve Django / Drupal etc.

I myself have spent a lot of time weighing in the pro's and cons of SPA vs.
Non-SPA for a recent project.

It's not like _all_ new projects are SPAs.

------
cloverich
Kudos for the open and honest assessment, I enjoyed reading it. Some feedback
for your journey: Drop the focus on languages. Choose one (popular) language
and focus on understanding it well. The best thing you can do, is find some
open source project with high quality code in that language, and study it.
Slowly, how long it takes does not matter. The end result is you will pick up
best practices and styles you did not know exist. Concomitantly, study a few
frameworks in your chosen language. Ex: If you select python and are doing web
development, learn how Django and Flask work. Learn how the requests library
or a forms library works. By reading good code, and studying frameworks and
libraries that solve peoples real problems, you will build a foundation for
how to put together higher quality and longer lasting code. That will not only
make you better as a programmer, and better in your chosen language, but
you'll start to find that a substantial portion of what you learn will start
to transfer.

~~~
Raphael_Amiard
> Drop the focus on languages. Choose one (popular) language and focus on
> understanding it well

While I understand this advice, your mileage might vary. I had the exactly
opposite approach and did learn a ton of different languages, on the end
making it my area of expertise as a compiler developer and language designer.
Of course that's niche, but knowing only one language will eventually become a
blocking point for every developer, especially in the modern world.

------
dave_aiello
Think of this essay as a barbell, in the investment sense of the word. The
beginning and the end of it have some really good insights that can be
generalized to a lot of technical / development work.

The middle of the essay (Rules 4-16) are useful observations from Mickey's
experience. (I don't know him; I am just trying to relate this paragraph of
comments to his experience more explicitly.) This is not a bad thing.

If you are a 1x developer yourself who is looking to improve, I think you want
to read treatises like this and try to understand your fellow developer's
perspective.

Only truly brilliant developers can give generalized language and database
platform advice. The other people who give valuable advice at this level are
not developers, they are technology evangelists who have a track record of
success helping real developers.

------
jusssi
> #1 Rules are good

Only when combined with "Rules are made to be broken". Nothing is worse than
taking an arbitrary set of rules and turning it into a cult religion.

Other than that and some of the programming language rules (such an
opinionated topic) a rare, level headed treatment. Bookmarked for future
quotation.

------
skywhopper
I'm somewhat perturbed that the entirety of the "DevOps" section is advice to
get an SRE on your team because an SRE's job is to "be online after hours".

That's an incredibly dismissive and reductive perspective on the expertise and
insight that an SRE (or any ops staff) could bring to a project, and it sounds
like this person--or maybe their entire team--is doing a really bad job of
owning their own junk.

I'll make a note to be extra wary of looking into any SRE jobs at Amazon if
this is how they treat those positions.

~~~
kakwa_
This is indeed an incredibly dismissive view, only seeing the SRE as the poor
soul you offload responsibility of things running well in production, despite
the fact he is likely to have far less insight on what might go wrong and
means to fix things.

Being basically in this position (but in a large follow-the-sun team, so I'm
fortunate enough to not be paged at night), I can only underline the deep
frustration such views can generate. Being paged every 10 minutes, being asked
to fix things you have no control over, getting answers like "what? the server
is overloaded? it's an infrastructure issue, not a bug in our code" and seeing
developers cry when they get a ticket a day, when at the same time each SREs
in the team is receiving a dozen, it can lead to some resentment.

A saner approach is to have the SRE as the first line to filter
bugs/alerts/tickets out, but being able to call a developer if required. The
SRE can also be an active team member with more insight on production
constrains and pain points and maybe system architecture recommendations for
the whole team. Also, in my opinion, developers should be an active part of
running things in production, otherwise the whole dev team can lose touch with
reality and lose sight on how well or not things are actually running.

------
mmhsieh
God must love us 1x-ers because He made so many of us!

------
onion2k
This article really puts me off working for Amazon.

~~~
rezeroed
I only read the start. I'm not sure what I make of someone going from zero to
Amazon. Is that normal?

~~~
onion2k
Amazon recruit huge numbers of graduates, so obviously that's a yes. I think
their graduate roles pay quite well too.

But if this article is to be believed, they also do things like using 15
different languages on the tech stack (16 to choose from minus PHP because
it's banned) and give you the idea that estimates are worthless. If your
workplace is doing things like that it's a _very_ bad sign in my opinion.

~~~
akhilcacharya
> they also do things like using 15 different languages on the tech stack

Teams have a lot of flexibility to choose the best tool for the job. It's not
surprising that you'd have those options if you're tackling everything from
UAV avionics to distributed systems to facial recognition.

~~~
onion2k
_It 's not surprising that you'd have those options if you're tackling
everything from UAV avionics to distributed systems to facial recognition._

Amazon _as a company_ might use them all, but no Amazon team should be
choosing between them all (well, they do in so far as you can immediately rule
out lots of unsuitable languages for most projects). This guy has worked on
two teams so far and appears to be suggesting he's made choices between _15_
languages already. That either means the teams he's been on have used _wild_
stacks with endless choice (a reason not to work there) or that he's not
correct about the extent of choice he had (and if someone has 5 years at a
company and they still don't know that's another reason not to work there).

------
flavious
> Rule 20: When somebody says Agile, push for Kanban, not Scrum

From my experience, scrum is better. The idea is that you can measure progress
and you can learn from mistakes with scrum.

Kanban doesn't help in that regard.

Also, a good scrum master will tell you some things:

\- a successful sprint is one in which not all stories were finished, because
the goal was ambitious

\- do not sweat over spill-overs; they happen all the time, it's not the end
of the world as long as you work 8h/day really focused and give your best

I know that in the US you got modern slavery with insame working and commuting
hours, but life is decent in places like Europe.

------
beefbroccoli
> Try to push as much logic as possible to the server. If the front end
> weren’t super complex, I would consider something like Phoenix instead which
> actually pushes everything to the server.

Sometimes you don't have or don't want a server, but still want to avoid the
issue of wedding business logic to the UI.

With web apps my strategy is to treat business logic as a separate library
housed in the same project. I'll have a "SomeBusiness" directory and just
import it across the project like I would a third party library.

------
Tade0
> At first it was pretty simple, but then we got a lot of new frontend
> requirements and in no time, managing the front-end state was a total
> nightmare

If there's one thing I envy backend developers it's the fact that they don't
receive even half the requirement changes the front-end does.

But I would refrain from pushing as much logic to the server as possible -
it's never the better experience for most users in comparison to striking a
balance between having it all on the server vs the client.

------
technofiend
Maybe I'm being naive but I'm privately nursing this hope that at least for
devops / SRE roles people do want folks with plenty of operational experience?
I mean I still expect they'd want to see someone keeping up with tech stacks
and facile in a modern language or two so the interviewee can fix issues and
contribute enhancements but still is a depth of experience at some point
really a hindrance rather than a help?

------
29athrowaway
You become more productive by delegating work to the computer.

The better you are at delegating work to the computer, the more productive you
will be.

Algorithms are elegant, data is not. If you are not careful, then data will
leak into your program and you will end up with special cases for everything.

When this happens, your job becomes a glorified data entry job.

But you can be smarter than that and create abstractions over data that are
reusable. And most likely that will involve types too.

------
maps7
I'm not sure how I should be reading the article so maybe it's going over my
head.

> Rule 10: When to make a microservice

> I would use a microservice when I have a relatively small and simple chunk
> of code that needs to run every once in a while.

Isn't this wrong? There's no reason a microservice should just run once in a
while. It also creates a lot of complexity for a simple chunk of code.

~~~
codingdave
Most of this article could be ripped to shreds based on its accuracy. But that
isn't the point - he has developed a set of rules and guidance that work for
your average developer just slinging code in an enterprise. And while yes,
almost everything he says is "wrong" if we push the details... I can see that
they are all "close enough" to build a workable framework for your basic 9-5
1x dev.

~~~
hamburga
> almost everything he says is "wrong" if we push the details

Author here. Part of the point was to expose my ignorance and get people to
rip it to shreds. So have at it if you want. I've actually learned a good
amount so far using this method.

------
mannykannot
Rule 14: When to Write an End-toEnd Test

4\. When your spacecraft needs to get the correct mission elapsed time from
the launch vehicle.

[https://arstechnica.com/science/2020/02/boeing-
acknowledges-...](https://arstechnica.com/science/2020/02/boeing-acknowledges-
gaps-in-its-starliner-software-testing/)

------
freewilly1040
Not sure I entirely agree on rule 18. My current team probably cares about
estimation more than any previous one I've been on, and it's functioned more
to keep engineers aware of prioritization and what is blocking. The team leads
have definitely made it a point of emphasis to not put pressure on finishing
sprint tickets, though.

------
di4na
A slight point on Erlang:

Erlang is good on business logic and not really good on making something
"mathematically nice". It is more in the same place than the one you give to
Go/Rust. Low latency good performance and great reliability (these things are
linked) for web is a classic use of erlang or elixir.

------
dnautics
Erlang (and elixir) are very unfairly bunched with Haskell since they are both
functional languages; in practice they are functional in form and in the
large, but they make compromises which really make them "a working person's
language", not something to live in the ivory tower.

------
chapium
This notion that during non working hours I should still be working on side
projects is absurd.

------
alexandercrohde
>>> To replace out MediaWiki with a Java-based alternative (XWiki) ended up
taking a total fo 24 dev-years over 4+ calendar years for the team

He can call himself 1x, but if he can stop just 1 colossal failure like that
he can easily become 10x.

------
jb3689
Heck, writing this post is enough to be at least a 1.1x dev. I don't subscribe
to the whole "x developer" thing, but this is an amazing list

------
Shorel
I think nothing is truer than rule 16.

"If you delegate all your IT security to the InfoSec, they will come up with
Draconian rules"

------
alcover
> front end [..] consider something like Phoenix

install = install Erlang + install Elixir + install Phoenix

Well.. I'll stick to Node + vanilla JS

~~~
mm89
Installing something is easy, learning how to write Elixir/Phoenix/maybe
Erlang is the hard part.

Don't ever let "installation" prevent you from trying something, on Mac it's
literally "brew install elixir" followed by a command to install phoenix
framework.

~~~
alcover
You are right and that is what I meant.

Sometimes though installation is a real pain. (For ex. OCaml/OPAM on Debian)

------
padseeker
I enjoyed reading this, although I should note that I agreed with the non-
technical advice way more than the technical.

------
5cott0
I'm only a 3x developer but I'm still _hardcore_.

------
kyberias
> I would use a microservice when I have a relatively small and simple chunk
> of code that needs to run every once in a while.

Is this a joke? Why write such nonsense when you must know you don't know
anything about the subject?

------
austincheney
There is so much that is wrong with this.

Follow this advise only if you are currently employed and your employment is
extremely safe because your employer is deemed essential or because they are
financial strong in the current economy. For everybody else very carefully
consider why an employer should hire you when the current economy is failing,
programmers generally are very expensive and add very little value to the
employer's revenue, and why you are a better value than the other 1000
developers that were just laid off. The economy is never going to be the same
and the common suspicion moving forward is that software hiring/practice will
also change to compensate.

The article opens with having kids and so they cannot work more than 8 hours a
day in a specified time slot. This is an absence of ambition and nothing else.
Work-life balance takes some figuring out, which isn't avoidance. I have two
white-collar careers in unrelated industries and kids. I have time for both
jobs, coding on the side, spending time with my kids, helping my wife prepare
dinner, and so forth. I am not unique with this regard.

The bit about _How to do Javascript_ is really bad advise. This is largely the
story of my career in the corporate world as a JavaScript developer. The
employer is mostly a Java shop because Java developers are easy to find since
they are effectively mass-produced by universities. The Java developers have
absolutely no idea what to do with any aspect of web technologies aside from
Spring MVC. JavaScript is required by the business, so the Java developer fake
it until they make it. They still have no idea what they are doing then give
up and require a framework. Epic fail. Any other industry would call that an
ethics violation, negligence, and that path would land you in a law suit or
possibly in jail depending upon the product/industry.

> So we went with vanilla JQuery.

That makes me cry. The programming section is followed by a section on testing
that almost makes me angry. Many of the use cases provided for writing tests
explicitly mention low confidence on the part of the developer. Horrible
advice. The things to test are features and use cases. The software does all
that it promises or it doesn't and there should be enough automation to prove
that. How you go about that depends upon the product.

The security speaks like somebody who has absolutely no idea what security is.
When you have absolutely no idea what security is or why the company would
spend so much money on it I too would think everything about it is draconian
and worthless. So many software developers seem to think they are well versed
in security despite having no such experience, education, practice, interest,
or credibility and I have never understood why.

~~~
jimbokun
> programmers generally are very expensive and add very little value to the
> employer's revenue

Then either they are very bad at their job or working at a very bad company.
Software companies have some of the highest revenue per employee numbers,
compared to other industries.

> The article opens with having kids and so they cannot work more than 8 hours
> a day in a specified time slot. This is an absence of ambition and nothing
> else.

Many developers who work 8 hours a day accomplish more than many other
developers who work 12 hours a day.

~~~
austincheney
Most developers don’t work for software companies.

------
scooter_de
As he said: He's a 1x developer.

------
jeffrallen
I would like this guy as a colleague.

------
danielovichdk
This must be written by a developers with only very little experience.

Generally very shallow advice and poor or no discussion on why.

~~~
freewilly1040
Ironically this comment is quite shallow and lacks any contribution to
discussion

------
mdszy
Rules of thumb for a 1x developer: Stop with the 1x/10x bullshit and quit
basing your self-worth on your ability to provide for an employer.

Fuck sake.

~~~
whateveracct
it's capitalist hypnosis

------
OOPMan
"Rule 5: When to use Python or Ruby Python and Ruby seem to me to be pretty
similar in that they’re scripting languages and dynamically typed and seemed
like the greatest thing in the 00’s. You use them when speed is more important
than legibility or debugging. And then Python for ML/AI applications."

Eh? Speed? What kind of speed? Developer speed? Code speed?

Why is legibility in Python/Ruby bad? Bad compared to what?

Why is debugging in Python/Ruby bad? Bad compared to what?

Frankly...this feels like a 0.5x article to me

~~~
hamburga
OP here. I know that these rules of thumb gloss over some of the details, and
it's this kind of ruthless criticism that I wanted to invite with posting this
:)

I'm coming from the perspective of a tech giant, where there are thousands
(tens of thousands) of services, and it's often a huge challenge to trace the
flow of data through any given system or API and pin down the cause of
production issues.

The static typing with Java gives us a lot more guarantees about the data
flowing through systems, compared to Python. If I want to inspect some code or
debug a production issue, static typing gives me a lot of guardrails. I can be
sure that data coming in is of a particular shape, that null constraints are
met, etc. Whereas (from what I can tell) it takes a lot of extra work (and
more possibility of missing something) to do the same with Python or Ruby. But
I haven't ever built a Python or Node service or whatever.

That's what I meant by legibility and debugging speed.

If you define legibility as "can understand the purpose of the code," I do
think that Python can be way more legible since you've got so much less
boilerplate.

------
MaxBarraclough
This is poorly titled. A '1x developer' is by definition an average developer.
The page is mostly listing basic knowledge that any developer, even a very
junior one, should already have. If you aren't aware of the relative strengths
and weaknesses of Java, C, and Python, you aren't a 1x developer, you're a
trainee.

Anyone know of any better articles truly targeted at '1x' developers? (This
isn't snark, it's an invitation.)

~~~
laumars
The 1x / 10x memes need to die in my opinion.

~~~
MaxBarraclough
Agreed. _1x_ should be a synonym for _ordinary_ , but as we're seeing here,
its meaning had drifted to refer to especially unskilled developers.

