Nice post! As a software dev of more than twenty years myself I nodded along with most of this list.
I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth.
Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them.
For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.
> For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
The junior/senior distinction is so coarse-grained. Expert research sometimes uses nomenclature inspired by guild terminology, e.g.
- an initiate has just started learning the subject;
- an apprentice has basic knowledge but still needs guidance from someone more experienced to go through their day;
- a journeyman is skilled and reliable and can go through a day's work unsupervised but still need direction from someone more experienced, many people are journeymen for life;
- an expert is a top-level journeyman who is looked at as someone who can deal with unusually tough problems;
- a master is a leader in the field, someone who can train experts.
It's not perfect, but it's a strict improvement over what we are doing now.
I especially like the operational definition of when one goes from an apprentice to a journeyman. It's a fairly obvious distinction: can you do a day's work unsupervised? Much easier to determine than when one goes from junior to senior.
I'm coming from a culture where this scheme is still applied to various crafts. I agree very much and think it would fit quite well for software engineer, though I think starting at the expert level there is an element of research / scientific thinking needed that academia tends to produce better results for.
The ideal career path would thus IMO involve some way to combine this vocational proficiency with a research stint, be it in academia or in industrial R&D. Switzerland is I think rather unique in allowing this combination, but by far most people (me included) still go through either one or the other (vocational vs. academic route).
Germany? I work with Germans and I always worry that their apprenticeships mean something different to what I have in mind. Do you have a link or something explaining how those skill levels are interpreted in your culture?
Switzerland in my case. It's quite similar, but with some extended vocational university options compared to Germany ('Fachhochschule'). Anyways, the way it generally works for most professions (and ~75-80% of population actually go through this route, rather than going straight to academia) is as follows:
* start apprenticeship at 16 for 3-4 years; 3-4 days per week of being embedded in a company as apprentice, 1-2 days of staying in school
* at the end of apprenticeship you do a test, both theoretical and practical. your 'apprentice master' (Lehrmeister) is judging your practical skills in form of an apprentice project. Passing that you're the equivalent of journeyman.
* you can now either start working full time, or you go back to school for 1y to get the federal professional maturity test ('Berufsmatura'). This allows you to enter any higher vocational school in your field in the country.
* from here you go on to either do a vocational university, or you could even take another test and go full on academia (say to ETH Zurich, University, whatever). That gives you the equivalent of BSc or MSc, depending on where you go and how long you stay.
* On top of the bologna titles, there is also the 'federally certified' titles. Say you wanna be a certified construction manager, you go do a federal certificate and become one of ~2500 people in the country with that title. It's highly sought after and a sign of quality. Think of it like professional master titles given by the French state, if you reach that you should never have to worry finding a job. You'll generally be >30y old at that point.
Now I'm curious so I'll pick your brain a bit. What happens if you want to change careers later in life? Do you go back to apprenticeships with other 16-year olds, or is there a different path for adult education?
And when you start a BSc at the earliest, you are something like 20 years old? (16 when you apprentice, 19 when you finish that, one more year plus two tests to enter university?)
I‘ve never seen adult apprentices, don’t think it exists. Rather you‘d do internships and evening schools, as everywhere else. The difference mainly comes from apprenticeships being the norm for teenagers, it creates IMO an environment of comparatively high skill levels in all kinds of trades. Maybe not too surprising that Germany and Switzerland are generally good at machines and fine mechanics.
20ish sounds about right - in Switzerland, men loose a year due to military/civil service.
We had someone doing an internship in our SWE company (Switzerland) whom I estimated about 60 years. But never heard of someone doing an apprenticeship beyond late twenties or so (may exist, though).
To be honest, I find the idea of classifying people from journeyman to master rather unsuitable for today's knowledge work. It does not pass the smell-test for gate-keeping.
What you need to know changes every five years. Call someone grand-master of software engineering, sure, but no matter how great they are they'll not get your CRUD database UI done any faster - if their career was all about signal processing for particle accelerators and medical device certification. More likely, they'll over-engineer and over-spec and not be prepared for requirements to change completely after a year, or for sinking several days into CSS layout issues. Beyond a certain baseline of experience (say, working five years in the field or so), what counts is knowing the domain well (interpreting what the customer wants). Or already having experience with the technology that applies to problem-of-the-day. Or being highly motivated to learn it.
It's not like crafting with wood. The nature of wood doesn't change every six months. The tools we use to work wood don't change every six months.
I like the craftsman analogy, and have used it myself. Maybe to attain "master" certification, software developers should be required to create a "masterpiece" the same way as craftsmen of old (this being the origin of the word - a piece of work that demonstrated your master-level skills).
Perhaps a compiler or something of similar complexity would be appropriate as a software "masterpiece". What else, I wonder?
I'm not sure what you're referring to as "BEAM". Google throws up a bunch of different software related things.
An operating system such as UNIX would for sure count as a "masterpiece", but I think that's really too big of a project. Should really be something that a single "master developer" could complete in a few months, or less than a year at least.
I also have 20 years of experience, and was thinking the same thing about the article. Liked everything except the opinions. But for me the reason is a bit different.
Everything has benefits and drawbacks, and you always know the drawbacks of something you use better. Decisions are always about tradeoffs, never about "strong opinions". For example we recently had a discussion about git normal merge vs squash. My opinion was "I lean towards normal merge, but maybe in our context we prefer squash. Let's check with the team members...". Now if you have a strong opinion on either one, I know you are inexperienced, because you cannot just throw away the benefits and drawbacks of either one. You might fool juniors who equal strong opinion with knowledge, but not me.
And on juniors vs seniors, the biggest difference I see is that juniors can really get stuck on a problem, with nowhere else to go. A senior is always able to find a way.
Ironically, you have a very strong opinion on people with strong opinions. Going as far as saying if you have a strong opinion on how to use git means you're a junior is a bit extreme, in my opinion.
I’m sure you could change his mind with a good reason. What reasoned argument can you give as to why it would be better to have a strong opinion about why one type of merge is always better.
Maybe you’ve seen the long term affects of squashing commits in several different contexts, and it always leads to a poor outcome eventually. Sure there might still be reasons to do it, but you’ve never seen a case where it’s worth the cost in the long term. Eventually with experience (and several different contexts), you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
Maybe this doesn’t actually apply to git merges, but I imagine that there are certain things that eventually emerge as having extraordinarily unfavorable trade-off ratios.
It’s hard for me to think of anything off the top of my head, but one example could be using global scope for all of your variables. Sure, it’s a small app now, but do you really want to rewrite everything later when it’s impossible to understand? Of course there are (tiny) benefits to building an app with all global variables, but it’s hard to imagine that is ever a worthwhile trade-off, and I think it’s fair to build a strong opinion that you should use (at least some) local scope.
> you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
I think a "measured" approach here would be to say that the evidence required to convince you that this would be a good idea raises which each new domain in which you see it fail. It's not to say that you cannot be convinced; but it's to say that the burden of proof is heavy.
I think it often is the "multiplication" of severity and frequency. Once burned badly enough gives a lot of weight to your preference, even though it is not what you typically associate with the word "measure".
It seems like you do have a strong opinion on git merge vs. squash. You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them. (You even go as far as saying that the latter is a signal of inexperience!)
For me I have found different paradigms to be useful. But sometimes just getting the team to agree on one system and one set of build tools can be an uphill battle. So sometimes you end up with 2 or 3 systems instead of one. For some things that is perfectly fine. But others it becomes a roadblock on bringing in new people. When starting a new job sometimes just where the bathroom is can be a bit of a chore much less trying to figure out what someone 3 years ago was arguing about and you just want to check some code in and get it reviewed. But when you first show up you probably at least want to get a lay of the land and figure out where the Chesterton's fences are before trying to 'fix it'. It could be they already had this discussion a few times. It could be they never considered it. But until you do it their way for a bit you will not be able to speak with any authority.
>You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them
If there ever was an universal truth about any subject that's being dealt with by someone who knows even a little about said subject, it would be phrased approximately like that
"Don't be a zealot about $thing" shouldn't be considered a strong opinion
I remain a zealot about the harms of leaded gasoline and corruption, for example. Also the roundness of Earth, and the applicability of Newtonian physics at human scales. There are a large class of things you should be zealous about if someone offers opinion to the contrary!
Well that's such a topic that it's not really worth to have strong opinion over yes, but there are other things that will determine the success of an application or system, like whether you use REST, GraphQL, micro-services etc, so the architecture of those things, having knowledge to form an opinion about those would seem important. These type of things can matter in the future where they could have 10x productivity difference depending on the path you choose.
I've had great success with opinions. I'll solicit opinions and give my own. Opinions are a kind of chaos monkey for checking your assumptions and bringing aspects that you hadn't thought of into the discussion.
And since they're all coming from various sources of experience, they're going to be useful.
The trick is to not treat opinions as correct/false, but rather as components that help push your solution towards the limit of correctness. It's incredibly rare that a single opinion solves all.
The way I read the post is, the particular opinions that a senior engineer has are not very important or valuable.
It's that having strong opinions about your tools means you've used them a lot and have an emotional connection to them - be it positive or negative. Which is a proxy to caring about your craft.
The issue I have with this principle is how the strong opinions are presented. It's often not easy to tell the difference between "an inexperienced, non-authoritative, strong opinion weakly held" and "an experienced, authoritative, strong opinion strongly held".
If it's obvious that you're a junior dev -- that you have both little experience and little influence -- then expressing a strong opinion isn't really problematic, because other people will feel comfortable challenging it.
The problem comes as you start to gain experience and influence. As it becomes clear that you do have experience in general, then people are likely to assume that all of your strongly stated opinions are the result of experience, even when they're not. Thus people with a little bit of experience in X, hearing your strong opinion on X (even though you have zero experience) are more likely to discount their experience, rather than sharing their experience with you.
Similarly, people who are coming from the outside -- say, people from other companies talking to a team lead of a project; or contributors submitting to an open source project -- are more likely to hear opinion X as being, "This is the rule for this project", rather than "This is my current opinion, but feel free to challenge me if you think it's wrong".
So if you're going to hold strong opinions, you need to make it clear when you express them that they are in fact weakly held; and the more you grow as a developer, the more important it is.
I have heard of an anecdote that in some company, can't remember which, when meeting to take a decision, they would have people speak up in order of seniority, from the most junior to the most senior in the room. That way they could avoid the problem you're describing: you don't risk contradicting someone preceived as more experienced, or worse, your boss.
I found that an elegant solution, at least in abstract, I've never actually see it in practical use.
I can see how this sounds good, but my first reaction is that I think it is the kind of thing that would work great in a really good team that wouldn't even need it, and it would be awful for juniors in the kind of team that would get really excited about implementing it. Who wants to speak up when you don't know the ropes, you haven't gotten used to the social dynamic, etc? Seems to select for people with excessive confidence, who already have no difficulty advancing themselves.
This model seems insufficient and exclusionist to people who are socially withdrawn, or have a social disability, or come from a marginalized background, or any of the myriad reasons some developers already don't speak up. But it's a good starting point. I just would not implement it without additional frameworking to guide and encourage useful input from the juniors. In which case, if you're putting in the effort to understand why people aren't speaking more freely, this framework may be superfluous (or it could still be a valuable part of your practices).
That’s generally a good approach: it gets the thought out there, and others can take it under consideration, but without causing an ego wall to be erected.
If the subject is too important, you can “kindly emphasize”, but after that you’ve done your duty, and when the shit hits the fan, you’re covered.
It's not... you can feel really good or bad about something, but also be completely open to having your opinion shaped by new information and be willing to switch. That's what it means. As opposed to strongly holding opinions (whether they are strong or weak) and actively resisting conversion attempts.
The opinion itself is strong because it's absolute. It will be weakly held if, when presented a case where gotos really are a better solution, you give it up and decide to modify it to, "Never use gotos, except in a handful of well-defined cases, such as X."
Thanks. I think I am already following that policy. "Strong Opinions Weakly held". But generally, people see your strong opinions and automatically think you are difficult to work with or make some assumptions about you. They do not care about the "weakly held" part. Atleast, that is what I believe. But it works personally very well.
I interpreted the author's stance on opinions differently. I believe he meant that having a strong opinion on tools and architecture is a signal. A signal that the developer is battle tested, been there and done that, and have the scars to show for it.
When I read the bit about having strong opinions, my personal reaction is to recall when my team(s) wanted to ditch SQL Server for first MongoDB and then later CosmosDB. I physically felt sick.
IMO it has a lot to do with the how well the person is able to pick their battles.
Like, IMO it's weird if you DON'T have a strong opinion about tabs vs spaces. But if you're getting into serious, protracted arguments about this, then you lack the wisdom to prioritize the decisions that really matter.
I somewhat disagree. I think you can challenge yourself.
I'm typically the type of person who keeps my opinions to myself unless asked and when I disagree with someone about how to do/build something I'll do it myself on my own time. Sometimes I'm right and sometimes I'm wrong. As much as it sucks to realize I'm wrong I do appreciate it because it means I learned something and my opinion has improved.
The state of the art is not subjective in the sense that each individual defines their own (although in much of the software industry it can certainly seem that way). Take the SWEBOK [0] as an example. It is a collection of many individuals’ contributions to the body of knowledge; not just some conference speakers’ opinions.
Not everyone maintains or collects together all of the practices in their domain; software moves fast, so sometimes we have to rely on individuals’ experience and wisdom to know all of the different approaches, for example, to software testing in their domain and which ones are best suited to the project at hand.
Their opinion isn’t terribly useful if it goes against the requirements and specifications.
> We should be far more focused on avoiding 0.1x programmers than finding 10x programmers ... The 10x programmer is a silly myth.
I've worked with far too many 0.1x programmers, too many 1x programmers to count and maybe a handful of 10x programmers.
I always flabbergasted when people say things like "The 10x programmer is a silly myth." ... have they really, in all their years, never, ever worked with a superstar?
I worked with a guy who wrote the framework of a medical imaging system almost entirely by himself; hundreds of thousands of lines of FDA design systems quality code complete with tests that formed the backend of a successful product that was used on almost every MRI and CT scanner for years all while mentoring developers all around him.
> I always flabbergasted when people say things like "The 10x programmer is a silly myth." ... have they really, in all their years, never, ever worked with a superstar?
I have been in situations where I'm the 10x or even 100x programmer. For a while, on some project. When everything aligns just perfectly, where I just happen to know all the right things and happen to have all the needed authority and independence.. yes, it feels magical.
But I'm under no delusion of being a 10x programmer. To me that means someone who is consistenly 10x better at everything on all projects always. That doesn't exist.
A "10x programmer" is, I think, a kind of goofy term.
In 26 years working at Apple, I can think of a dozen or so engineers that were remarkably capable, prolific, able to hold an entire code stack and all its esoteric nuances in their head, could handily see how to refactor an entire framework, or replace several frameworks with one.
I don't know if I would call them 10x programmers though — as I understand how the term is being used.
But I can think of two, maybe three engineers that I would say were so far above everyone else in ability that I absolutely would call them 10x programmers. They were seemingly able to additionally hold in their head the working of the processor, its registers, the idiosyncrasies of the compiler and linker, how the low-level file manager and thread managers work.... It was clear to me that they just think differently.
I recall a bug that I wrestled with for days (and other coworkers were stymied as well). Out of desperation I asked a 10x-er and the bug was resolved in 5 minutes. Remarkable. I even asked him how he saw the problem so quickly but even his answer was gave me no comfort. It was, as I say, clear that I just didn't think that way.
> I recall a bug that I wrestled with for days (and other coworkers were stymied as well). Out of desperation I asked a 10x-er and the bug was resolved in 5 minutes. Remarkable. I even asked him how he saw the problem so quickly but even his answer was gave me no comfort. It was, as I say, clear that I just didn't think that way.
I never understood how normal people program. I have an extremely good long term memory and my intuition somehow internalizes every codebase I see so it just tells me what could be wrong and then I fix it. So every time I come into a new team there are stuff others have struggled with for a long time, and I just go and solve them, people with way more experience and have been there fore years, doesn't really matter, they don't see it.
I have many other mental issues so I am not really a 10x employee, but the gap in how fast people can reason about technical problems is extremely huge. I've worked on one of the more important teams at Google, there were a couple of extremely good engineers there, but most were just normal hard working people, the gap is huge even there.
The ability to pay attention on a specific thing for more than a few seconds doesn't feel "natural" to me. Evolution does not favor long-term attention for anyone who is not a top-predator. Imagine a deer paying too much attention to grass It's eating and not able to be distracted by the slightest of the noise a predator may make is not going to reproduce. We, humans, are close to top-predators, so, maybe! I've not thought about it too deeply. But I still feel that the ability to focus for a long time is a bug, not a feature in the natural environment. The economic system has turned into a must-have feature and lack of it a bug that is to be cured by medicine. I wonder if early pioneers (not the sciency/nerdy kind) all had ADHD?
I can't pay attention to anything at all, its all reactive. You can get through college that way, just memorize and build intuition for everything, no need to work for that, but after college I couldn't do shit since nobody pays you for just knowing things, so got an ADHD diagnosis, got pills.
Without I can't even read a single line of text without losing focus, I just read fragments. Then when I got pills after college everything became super easy. My intuition was already an expert at reverse engineering technical facts from fragments of documentation, so when I suddenly could sit and realisably read things for hours everything just clicked. Maybe that came with the ADHD or the other way around, I don't think it is entirely free.
There’s also a correlation with childhood trauma and attachment.
Grew up in mostly harmonious and safe environment? Better focus and easy control over attention.
Unsafe, startling environment demanding a deer-like constant awareness and adaptation? Less control over more scattered attention habits and the related issues with memory.
Like... debugging? Following the code process and seeing where it breaks? I'm a little unclear, are you saying you don't do debugging, but rather when you see a bug you mentally run through the entire process and know exactly where the bug is... even in a new codebase?
If you wanna experience the other way around, work with normal people using computers.
They usually struggle and get by through habits but they understand nothing (which is normal, computers are anti-pedagogic), while developers can see through the fabric. Things that are obvious for us are non existant or merely a huge stack of blurry artefacts with no clear order.
> where I just happen to know all the right things and happen to have all the needed authority
This is such an important part of the 10x programmer formula. It’s no mark against their talent or skill, but the environment and team is largely the deciding factor on developer productivity.
I’ve been a 10x developer and a 1x developer on different teams. Ive found it really depends on the environment and my peers.
Definitely. I'd like to better understand the extent to which environment is a factor. The author mentions that too:
> Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.
Coincidentally, today I was listening to "Surely you're joking Mr. Feynman". He talks about almost 10xing a team after telling them about the formerly secret projet that they had been working on.
Yes this 100%! The contrast in my productivity and what I'm able to achieve from company to company is simply staggering, and is usually more a testament to the company's culture fit (with me) than my own technical skills.
For example last year I worked as a freelance front end engineer in a corporation building graphic design tooling. I had previous experience in this so initially it seemed like a great fit, but the culture clash between their "everything has to be perfectly designed and implemented" way of working and my ... well, let's call it pragmatism (YAGNI is my guiding star), was so large that I found it difficult to get anything done.
Contrast this with my current company where we have a lot of freedom and autonomy to design and build systems, and the end result is what matters: I don't know if it's 10x, but it's definitely on the other end of the scale of productivity.
> To me that means someone who is consistenly 10x better at everything on all projects always. That doesn't exist.
At the far end of the distribution, they definitely exist and some are like 100-1000x.
I work with someone that can pick up a new language and be writing fluently in that languages’ idiomatic style in a weekend, delivering robust, scalable, concise code.
He can learn a new domain and understand its nuances so quickly that he often becomes more fluent than the company ‘domain experts’ after just a few weeks’ of effort. And no… this isn’t shallow stuff. We’re talking domain experts with Ph.Ds in EE from MIT. He drives industry standards and has the patents/resume to show for it.
The thing is… everything he touches turns to gold. From documentation to design, implementation, test code, infrastructure, maintenance… he does it all.
I’ve worked with smart people (friends/former colleagues at various FAANG staff eng level people). This guy is next level compared to anyone else I’ve worked with.
> He can learn a new domain and understand its nuances so quickly that he often becomes more fluent than the company ‘domain experts’ after just a few weeks’ of effort. And no… this isn’t shallow stuff. We’re talking domain experts with Ph.Ds in EE from MIT.
I have to be very skeptical of this. If the person is so superhuman and famous, can you name them?
Nobody gets to look at a new field and quickly become a domain expert with more knowledge than those who've dedicated their life (PhD, career) to the field.
To be honest this sounds like a con artist good at talking themselves up.
He quoted the "domain expert" part, I'm pretty sure he didn't mean real domain experts, rather just the local programmer who happened to take most of the tickets related to that domain.
For example, early in my career I worked at a small company. They had an "SQL expert", but I got better at SQL than him almost immediately since he wasn't really an SQL expert. I wouldn't call myself an SQL expert today either, its just that the "expert" didn't even know the basics or how to work with indexes properly, what types of queries are fast etc. So he wasn't an SQL expert, he was just the guy who did tickets related to SQL, and then managers starts calling him an "SQL expert" to make his team sound more competent.
But if we take a real domain expert, for example a Math PHD, then not a single genius ever could learn enough to catch up within a weekend or two. Every genius in history in these domains has spent years learning them. I don't think anyone would claim to be able to do that in a weekend. But get better at SQL than a typical backend developer over a week? Yeah, I'd believe that.
EDIT: Saw that the above comment mentioned PHD. Yeah, then it is a bit ridiculous, at least if he meant that the person learned the equivalent of an EE PHD over a weekend, that wont happen. Maybe the guy found some error in the works of the expert and people blew that out of proportion.
I'm leaving the rest of the comment as is, but I agree with you, his story is a bit ridiculous if you take it at face value.
It might sound ridiculous. But this guy is regarded as a super star by an IEEE fellow or two. And by domain expert, I mean people that sit on standards bodies in communications theory.
This guy is out there on the tail end of the distribution.
So, you've dodged the question of who he is. How about the question of why his identity must be kept secret? It sounds like anyone anywhere near him would know who you're talking about anyway
Exact same thing I thought reading the GP. I've done shit just as impressive-looking on paper. I've also been the fuck-around who barely does anything, or have plugged away on mind-numbing low-value crap for months on end, none of it executed especially well.
"Real" 10x might exist but I think most times it's a combination of some minimum ability level, the work environment, the team, and, crucially, the actual tasks a person can get ahold of, that lets 10x manifest.
Some people probably manage to engineer their careers such that they continuously receive such work, and are able to reject or avoid work that wouldn't let them perform that way. That would look an awful lot like "real" 10x.
Meanwhile, sure, smarter people than me exist and they can certainly solve certain problems I can't. I don't think that's quite what "10x" usually means, though.
I can never let these arguments go. There are steady, consistent, 10x people in EVERY line of work, from flipping burgers to performing neurosurgery. There's a bell curve for any ability, and there are people who are on the far end of it, every time. Sports is the easily-understood example. Why should programming be any different? In my 27 years, I've written and rewritten software that different groups have also written. I don't want to write out all the details, but I've been a quantifiably-10x+ programmer at least 3 times in my career.
Do you have 10x players in sports? No! So it's a good counterexample.
The superstars are incrementaly better and work hard to be extremely consistent at being slightly better. That leads to becomeing a superstar because if you're consistently 0.1% faster than everyone else, you win most of the time. But 10x better? No of course not. It's not humanly possible.
Is the top track and field runner 10x faster than the middle of the pack? No, just a few fractions of a second.
Is Max Verstappen or Lewis Hamilton 10x faster than the tail end drivers who have to pay to play? Not even close, just a few fractions again and consistently.
Same for every line of work. There just isn't enough spread possible in human capabilities for someone to be 10x better than other professionals in the field.
(Important to note we're comparing to other professionals in the same field, not random people off the street who've never done the activity.)
I think this actually does illustrate how the possibility of 10x [performers] is perfectly valid. To build on your example, while it's true that that Lewis Hamilton isn't driving 10 times faster, he has 103 F1 wins while to the average pro driver has zero. Michael Phelps isn't ten time faster than his competition, but he has 23 Olympic gold medals while the average professional swimmer has zero. It gets a bit more convoluted with the positional team sports, but at a glance there are players in the same position, with the same overall career trajectories, who are earning significantly more than 10x their peers.
I don't think people are suggesting that 10x engineers are literally typing ten times faster than their counterparts, the "10x engineer" is someone who gets to complete solutions more efficiently — perhaps even 10 times more efficiently.
> To build on your example, while it's true that that Lewis Hamilton isn't driving 10 times faster, he has 103 F1 wins while to the average pro driver has zero.
Right, I'm not arguing (and I don't think anyone is arguing) that superstars don't exist in every field.
It's the "10x" part that is an annoying exageration. Nobody is an order of magnitue faster/better than other professionals in their field.
But you don't need to be 10x better to be a superstar. Being 1.01x better will do if you can keep it up consistently. That's enough to be always ahead and, except for the occasional error, most often win. It'll get you that 103:0 win ratio.
The consistency is the hard part. Anyone reasonably competent can be 1.01x faster here and there. To be the superstar it's not from being massively faster (as it's not humanly possibly), it's mostly from being very consistent at that 1.01x level.
I think Lewis Hamilton and Phelps — really, any athlete with household name status — are not just one but multiple orders of magnitude better than other professionals in their field.
I agree that the consistency is the hard part. I heard a take on this once that argued "10x" is more of a contingent state than something inherent to an individual, but if someone can consistently outperform their peers labeling them as such doesn't seem at all unfair.
The time it takes to write a program is closely related to how many things you don't understand well about such programs. This dynamic creates extreme performance differences between even fairly similarly competent people.
Example:
Programmer A is competent, he has good understanding about 90% of problems that comes up when he programs, so he has to stop and think and look things up 10% of micro tasks.
Programmer B is a bit more competent, he has good understanding about 99% of problems that comes up, so he has to stop and think just 1% of micro tasks.
The time it takes to finish is almost completely dependant on those parts you don't understand, the others you just fly through. So even though the understanding and skill of the above programmers looks very similar, programmer B who has fewer holes in his knowledge will likely perform about 10x better than programmer A. This makes programming very different from sports, in sports you don't run 10x faster just because you reduces your bodyfat by a factor 10 for example, so there those incremental improvements are barely noticeable since nobody who runs professionally has a lot of body fat.
> The time it takes to finish is almost completely dependant on those parts you don't understand, the others you just fly through. So even though the understanding and skill of the above programmers looks very similar, programmer B who has fewer holes in his knowledge will likely perform about 10x better than programmer A.
Agreed. I can't call that a 10x programmer though, it's just a matter of what is their field of expertise and how well it maps to the problem at hand. I'd say that stems from how we collectively use the word "programmer" (or developer, etc) to mean just about anything. Now move both A and B to a project domain where B has more knowledge gaps than A and suddenly A is the 10x programmer. But that means neither is really 10x, it just changes project to project.
To compare to other fields, imagine the top heart surgeon in the country. But then they get asked (for some weird reason) to do a knee surgery. Maybe they'll be able to muddle through it by remembering things from medical school and looking things up, but it'll be a much worse job compared to an orthopedic surgeon who does knees every day.
Would anyone in the medical industry say that this orthopedic surgeon is a 10x surgeon because they did it so much better compared to the heart surgeon? We can all laugh because that's clearly nonsense. But we use such comparisons in the software world as if they made sense.
Or to stay in sports, we'd never say the 100m champion is a 10x runner compared to the marathon champion. Sure they both run, but their skills are in different things.
I "believe" in 10x programmers. But sports is generally a poor analogy. You don't have anyone running 10x faster than the average running speed for example...
My mind goes to the Walter Peytons and the Michael Jordans and Tiger Woodses and the Serena Williamses, and so on. People who were so far ahead of the average -- even in a professional sport -- that they changed the nature of the game for everyone who has come after. It's not about pure score; it's about total performance.
You've got guys scoring 10x the points of other people though?
The reason it's awkward in sports is sports are head on competitive. Put a crappy team in a match with a good one and it's 10x. Two teams of equal skill don't seem like there is a lopsided talent.
Lets say that person A can reason about 1.5x more complex problems than his peers. His peers will be productive and contribute a lot of code until the codebase reaches their complexity limit, and then they start to really struggle. Lets say that A then comes onto that team at that moment, to A there is still plenty of room left before the project is beyond him, so he can work full speed as normal. In this situation A would probably contribute 10x more than anyone else on the team, not because he is 10x better but because he is still over that threshold.
> You've got guys scoring 10x the points of other people though?
Not 10x more than the median, I don't think.
(Happy to be proved wrong with a link to a player scoring 10x more than the median scorer[1]).
[1] In some games, like soccer, for example, it makes no sense to compare goals between strikers and goalies - goalies aren't expected to score, and so they almost never do.
Of course you're right about apples-to-apples but a guy like CR7 has scored quite a lot more goals than your average striker, surely? Keep in mind he also has had a longer career with more games, due to being really good. It's hard to say who is median because the not-top guys don't get that many games before they get sold to a lower standard team, or just benched.
Isn't it normal in basketball to have one guy dominating the points?
I think a better analogy would be e.g. scientists. I believe that there are certainly physicists who produce 10 times as much research output compared to the median.
But the real differentiator is in (both programming and science) the depth and quality, not quantity.
Programming/problem solving is a skill and is also creative in nature. It seems quite intuitive that ability follows some power law. Coming up with the Von Neumann machine takes a lot more capability than my meagre glue code I write layers and layers of abstractions above it.
I think denial of the 10x (or 100x) programmer arises from a few things. Firstly it hurts to admit that most of us are not 10x programmers but by definition this is true. Secondly many of us have not seen first hand how brutal talent/ability is distributed. Thirdly not all 10x-ers work well in teams and I've met fake 10x-ers who may be 10x more productive but at the expense of 10+ developers around them due to the inability to collaborate effectively.
On the second point, the starkest reminder is in music and sports - I've played piano all my life but am quite mediocre. My old teacher was a couple of leagues above me. Active soloists I've met are leagues above my teacher. Then you have a couple of the giants and they are in a league of their own. And yet universities and music colleges pump out thousands of really really capable musicians every year who will sound extremely good, just nowhere near the top.
Ronaldo/Messi or Federer/Djokovic/Nadal are also good examples of how brutal these curves can be. That an injury prone Federer in his 40s was still eclipsing all the rising tennis players is quite cruel for all those other top-200 players that have come and gone; who started later and retired earlier and yet also dedicated their sole existence to tennis.
If programming is creative in nature, then I'd see the modal developer as a rank and file journalist/copy writer. But dotted around are a couple of Wilde/Hemmingway/Tolkien/Orwell out there churning out text in their own special niches (or even creating their own niches)
Why do you use words like “brutal” and “cruel”? We celebrate those paragons - that’s why we have the Olympics. “Cruel” only makes sense in the limited scope context of single competitions.
And we should also celebrate hyper-effective programmers when we encounter them. There’s plenty of work to go around; they’re not taking jobs from others.
Have you watched Amadeus (the film). I like that movie for its exploration of the psychology of dedication being confronted by genius.
As outsiders of the sports, it is great to celebrate the GOATs like Feds Nadal and Djoko but a cursory google reveals that to reliably break even in the sport, you need to be inside the top 250 in the world.
To be 250th in the world at something like tennis takes a lifetime of graft and a tonne of talent, and yet the rift between 1st and 250th is still huge - you can often see #1 go extended periods without dropping a set and getting 6-0s which is a cruel reflection of the nature of the power law: you might be 1 in 100million but 1 in a billion talent completely wrecks you
EDIT reread your comment - totally agree with you regarding software vs individual competition.
I think the 10x concept is generally misrepresented - writing _code_ 10x as fast is possible, but not really important. It's people that _solve problems_ in a tenth the time that we're really talking about. And if you're not watching the numbers carefully, it just looks like every problem they walk up to happened to be easy instead.
I'll add that rework is an underestimated part of 10x, not that I'm 10x. The best engineers I've worked with create solutions that can be forgotten until the business changes, often 3-5 years later.
One variety of 10x pretender I've come across will slam out new systems that then require a lot of care and feeding. Flushing caches, re-syncing data, JVM or autoscaling tuning, regular addition of new special cases, version updates for yet another ecosystem... the list goes on.
Another facet of your "making it look easy" observation: management perceives the latter engineer as doing a lot more than the former, sadly.
I wrote a system in a year and a half, that solved a big need at my company for many hundreds of people. Another group -- the group that SHOULD have written it -- got mad that I had done it, and started their own version. It took 10 people 3 years to create their system, and it was terrible, slow, and didn't work the way the business needed it to, but they didn't care. It was so bad, they brought Microsoft in to try to speed it up, and even they couldn't do anything with it. Management changed, and my system was taken away from me, and given to the other group. They made a couple minor patches right after the handover, but, basically, it's run without handholding for about 6 years now, while they try to force people to use their system.
Nice to hear this happens elsewhere, a colleague and I wrote an alternative interface for some horrible internal web tool. I don't really know why the webtool was so slow, but it took _minutes_ to load data from the database and display it in a table. The table wasn't a real table, it was some fake canvas thing that lagged when you interacted with it, it was basically unusable.
Luckily the tool was writing directly to the database from the client, so we could get the database credentials and query it directly. Things that took minutes now took a few seconds. Plus, the data was append only, so we just cached everything locally and fetched new data only. Super trivial and basic stuff that made a huge difference to performance.
They found out, changed the database credentials and killed our tool. They did eventually make their version better, but it still kinda sucked.
I have a similar war story, from a university. The portal where students see their grades had several full-time consultants working non-stop for a few months and wasn't gonna be ready on time. The interface was confusing, and different campi were different business entities legally, so students required multiple login sessions if they took courses on different buildings (they had to pick a campus at the login page).
Teachers were about to be instructed to give grades to students via e-mail by the Dean.
I then saw the one database table on the teacher's portal DB that contained all the grades and knocked off a new screen in 1-2 hours in an existing system I maintained. A single remote database query, an HTML table, good looking layout. It was easier to use, more secure (SSO and 2FA), more performant, better looking and better-isolated (no DB write access needed).
The biggest hurdle was political, of course. I was probably too slow, to do it, if anything. But I was definitely 300x faster than the consultants.
I call them an "almost 10x'er" ... they pump out 10x code but it is a horrible buggy mess. I got pulled in to help one team that was months late on a release and found that their entire team was swamped with whack-a-mole bug fixing code that the "superstar" had written while the "superstar" was banging out new features for the next release. None of the features they wrote actually worked but they got the credit for developing those features and the rest of team was being blamed for not being able to ship the features.
So I get why people can be jaded by the whole 10x thing.
Yeah, 10x is not just about code. Another 10x developer that worked for me had a knack for writing beautiful, easy to use, domain specific frameworks that simply made everyone else on the team 2x or 3x more productive ... on a team of 10 developers. He was 2x-3x as a raw coder and probably 20x-30x for team productivity.
I've known people that are 2nd generation software engineers (have not yet met 3rd generation though). Their parents were software engineers, they were born with a bookshelf full of programming books, they were taught to program at an early age by professional programmers... They learned the rules of the game and received career advice at an early age.
The ones that make the most of those experiences are truly remarkable people.
It's easier to navigate your career when you are given a map at an early age.
I'm always surprised to hear this as well. The fact of the matter is software engineering is a vast field. The title is used to describe professionals with huge variances in competency. But they are all professionals (someone pays them) nonetheless.
This is apparent at every level. If you've ever hired fresh grads, you know there are resumes for people who have been programming since 15 in the same pile as people who have never written software outside of a school assignment.
At the senior level, you have people who have written the same application a hundred times with bad habits, in the same pile as people who's natural curiosity has lead them to understand how most of the hardware and software they touch works.
The idea that you would never come across a 10x discrepancy between 2 points in this distribution is silly.
> I always flabbergasted when people say things like "The 10x programmer is a silly myth." ... have they really, in all their years, never, ever worked with a superstar?
The 10x programmer is both part myth and part reality.
In a project that I initiated, created, delivered and then lead for years, I was literally 10x faster than the other people on the team.
On a project that I joined 3m-6m earlier, I was the 1x developer.
So yeah, you aren't going to make use of someone else's 10x developer unless their rate has been achieved in a field that uses your exact tech stack and in the exact same domain as you want, solving the same problems that their current domain needs solved.
Since you can't make use of someone else's 10x developer, they may as well not exist as a 10x developer.
Sometimes this is born from politics, and whether you have the freedom to be a 10x programmer, or are held back by externalities, opinions, and red tape. Anyhow, the fact is, there can be unfriendly environments to 10x programmers, and so it can be rare to find them there.
Exactly. I can be a 10x programmer, or I can be a 0.1x programmer. It all depends on my (external) work environment and (internal) motivation. I'll bet a lot of developers can say that, perhaps even the majority.
It's unenlightened to say that the 10x programmer is a myth without, as the author suggests, asking "why" a few mre times.
So your productivity vary by a factor 100? I don't believe that, unless you are talking about short periods. That would mean that you would do more work in 3 days in one situation than you did in a year in another. So either you greatly overestimate what you did in those 3 days, or you greatly under estimate what you did in that year, or you were in an accident and is now brain damaged.
I think it's possible. Mainly because it's possible for an organisation to slow to a crawl, with internal bickering. So it's hard to be much more productive than an ordinary functional org, but it's also possible to be doing basically nothing, thus any X is possible.
Maybe trivial but it does seem to be how it works.
Being 0.1x would imply that the average person on the team produces 10x more value than you do, so it can't be a byzantine organisation since it would hurt your colleagues as well.
It's happened to me a couple of times, but the time periods were short because I realized within a couple of months that not only was I (and everyone else on the team) horribly unproductive but that effecting change was impossible.
I've worked with 3 of them at different times in my career. They could do as much work as an entire team. One of the I worked with really well, I would feed him ideas and he would code the most incredible things, like parsers using ANTLR. He unfortunately committed suicide. Another one was the CTO of a startup, this brilliant Russian guy that literally did everything to keep the company running. The last one is ex-military that can single-handedly code extremely large systems but was kind of hard to work with because he was so much faster than me. I basically left him alone and fed on whatever breadcrumbs he wasn't interested in, and we co-existed well together.
The problem, I think, is that nobody agrees on which dimension the "10×" are measured. If only we did that, we could just measure and conclude definitively whether these programmers exist or not.
I suspect people prefer to argue about diffuse ideas, because it's more about the social exchange with other humans and less about determining what's factually true.
As a concrete example, I believe 10× programmers exist when measured in revenue supported or cost reduced. I have yet to meet a 10× programmer measured in profits! The 10× revenue/cost programmers I've worked with have had other quirks that negate many of their gains so they don't translate to profits.
I think you hit the nail on the head. I worked with 10x’s multiple times but there was also something off.
One colleague couldn’t be bothered to show on time. He’d still deliver but everyone was stressed because he could get lost for weeks. That moved him away from all more critical projects.
Other pivoted all the time. 1 week in - pivot - 2 months different attempt - pivot. Code was still used in other places until one day he decided to pivot his life and was literally MIA for 2 years (with police search etc.). He resurfaced in other country with different life.
Not so long ago I worked with dev whose output was mind blowing, he was closing stuff 10x faster than any other. Business gave him multiple raises throughout the year. He left for greener pastures though so we had to pick up his work and it was _bad_. Hard code everywhere, hard data, no abstractions. Adding metrics took weeks where they should take 1-2 days as it was standard process. Upon further analysis he got so fast because he ignored most of the development consensus. Ironically he always paired with 0.1x or short term contractors who didn’t care during reviews.
I think the 10x programmer in the sense of them being a great developer, with good perception and able to be highly adaptable and fast does exist.
The problem is they don't last long. Those kinds of people can do it for a few years, then burn out hard and become a 0.1x programmer for most of the rest of their career.
Being a 10x developer isn't a good thing. You're going to be spreading yourself so thin and massively overworking. That never ends well.
My issue with the 10x is it's overapplied at a programmer "macro" level. What I mean by this is I think every average programmer is 10x at _something_; but I've found that that something is not necessarily what a company wants, and even more tactically, not even the programmer can know ahead of time what that is. It feels (for me, anyway), kind of transient too.
Most of what I've written I'd consider basically average. I'm an average programmer, I'd like to think anyway. But a few things I've done I think are well above that. Maybe not 10x, but a couple things I knocked out quickly, got praise for, solved a real problem, and (AFAIK) are still in use today - even maybe decades later.
But did I know "this is my time to shine!" ahead of those? Not a clue. Things just clicked. And the things I thought I'd kickass with... some worked to varying degrees, some just sucked.
It just comes down to how people define “10x programmer”. Is it someone who is 10x more productive than the average programmer? Yeah this definitely exists. Is it somenone who will always be 10x more productive than the average in any given team, domain or codebase, from day 1? Of course not.
Without defining the term more precisely, people can discuss this forever without getting anywhere.
That's a good observation, there's a lot of goalpost-moving in those discussions.
I doubt Fabrice Bellard, Linus Torvalds or John Carmack would be able to come to my job and do 10-days worth of my work on their first day. Still doesn't make them 1x.
> I always flabbergasted when people say things like "The 10x programmer is a silly myth." ... have they really, in all their years, never, ever worked with a superstar?
I can completely believe it.
I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally).
I think it really changes by domain.
Full stack web development for example is about being a hard working programmer who writes good, clear well tested code. It doesn't take a genius to do this work well, it does take a lot of hard work and dedication.
I don't think I've ever worked with someone who produced 10x the value of his colleagues, no. Maybe there are a few who are the only ones in the company that can solve some esoteric bug because they've been in the company very long and possess the bigger picture, or because they are more talented or whatever. But that still doesn't make them "10x". It makes them more valuable and that's it. Not 10x.
A real "10x" dev is someone who gets product to focus on the right requirements or solves all kinds of miscommunications in the team and company, it has very little to do with actual coding.
That’s more like a 10X SWE. There are definitely 10X programmers out there, but they could be horrible SWEs (and often don’t work well in teams at all even if they can still create billion dollar products..though I guess 10x wouldn’t be a sufficient description at that point). Then again, I guess it depends on what you mean by dev.
Possibly, I've just never met one yet.
That's saying the guy contributes like 2 teams in his company, pretty insane. But again, I've always worked in companies that produced relatively straightforward software...the problems we are dealign with don't require a tremendous talent or creativity. They require patience, attention to detail, communicating well with product, hard work, etc. I could even see how being extremely talented can work against you sometimes doing this work. So there's not so much value in being 150 IQ (or whatever measure of ability we want to use) imo doing what I do. Sure you will be faster and better but no, you won't produce like 10 people.
A lot of 10x programmers you can’t really work with. They go off and create something like Minecraft, the company gets started around that, and then sold for a billion dollars.
Exactly. I don't build Minecrafts. I build big old web applications ...add a Python end point, create some React UI, all very repetitive and huge talent is pretty much wasted on that.
From my experience a "superstar" programmer is either somebody with Bi-Polar (works 40 straight hours) or a scam artist. Seen that playout now many,many times. A bi-polar worker can handle insane levels of work. it's just virtually impossible to keep up with them. Family member was a bi-polar canadaian air force pilot, physicist, and clinical pathologist that graduated from McGill and software developer (punch cards all the way through to Ruby). Nobody in his profession(s) could keep up with him...The other type of superstar is the bullshit artist. They slink away and start churning out unmaintainable garbage code that management loves. Than they'll disappear and the people that get left holding the bag are ".1x" programmers...I've seen those two scenarios play out a handful of times.
Worrying about being a 10x eng or not is like asking yourself if you are Einstein level smart. If you are not you are not. Just keep improving is all you can do, not enough people is gonna think you are 10x when you do become one, except in your imagination
This imaginary yardstick for measuring developer effectiveness is flimsy and appears mythical because it is extremely sensitive to context.
The same 100x dev who will build the medical imaging system single handedly, will also be a 0.01x dev when asked to fix an npm dependency issue in another team, will also be a 1x dev fixing a cassandra config issue, or an aws build system issue.
In my experience,
this is not because (s)he can't but mostly because (s)he WON'T.
In terms of code output the guy I worked with churned out more than 10x what I did. It was just a mess though, hence I had to fix all his shitty bugs. Especially as it was a lot code, on top of a really poor database design, using Mongo for what was relational data. Would have saved so much effort if he had used a proper relational database instead of chasing fads when Mongo was the cool kid in town
> Your data is the most important part of your system
This is true in pure code as well.
In coding, I believe there is a hierarchy, from most important to least important: data structures, algorithms, documentation/comments (not an original idea)
That's because if you change your data structures, your algorithms and documentation will break, you can change the algorithms while keeping your data structures, but it will break documentation, and changing the documentation will affect neither the algorithms nor data structures. So spend the most effort getting your data structures right, then the algorithms, then your documentation.
On a higher level, generally, data is useful by itself, code is only useful if it has good data to process, and documentation is only useful if it documents working code. Same idea.
I slightly disagree on priority. IMHO documentation comes first and that includes design (data structure and algo) decisions as well as managed expectations.
We all want to code. But the fact is - if we want to code correctly we need to write down and manage expectations with both our customers and ourselves.
(IE: “self documenting” code is one thing but stuff like “date display format” needs to be somewhere other than in a SimpleDateFormat line and if the customer/design team pivots, docs need updating first to drive the coverage in gaps.)
If documentation is how you get your data and code correct, than sure, it is important. But that's a methodology, a mean to an end. There are other methodologies that are not based on documentation, most notably, Agile.
But let's imagine. You use your documentation-centric methodology, and produce software, with good data structures, algorithms, and documentation. Problem is, your server room is on fire and so are all your backups, you can still recover some data but it may fail at any time, what will you try to recover first? I don't know about you, but for me, it definitely won't be the documentation (unless they are legal documents, maybe). If I lose the data and code, I will be left with nothing workable, I will have to do everything all over again, not from scratch because of the good documentation, but in the meantime nothing. If I lose only the documentation, future teams will have a hard time reverse engineering the code and all that, but in the meantime, they will still have a working product, and will still be able to do minor evolutions and bug fixes without too much trouble.
That's what I mean when I am saying that documentation is the least important. It means the least important as a product, it does not mean it is the least important to your methodology, or that you should not write it first, especially if you use it as a working document to make sure you get the other parts right.
Over “comprehensive” documentation, sure. But how much time is lost because the documentation isn’t available that would explain why the code is doing what it’s doing, or worse why different code wasn’t used?
> if we want to code correctly we need to write down and manage expectations with both our customers and ourselves.
Sure, the expectations come from code - types `Record<string, Banana>`, variable names `bananasByID`, etc. rather than some non-machine readable format.
> date display format” needs to be somewhere other than in a SimpleDateFormat line
The documentation I would have for this (for, say Swift/Kotlin/TS devs consuming the date display format) is
The date display format is taken from the Java SimpleDateFormat using "EEE, d MMM yyyy HH:mm:ss Z", see https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
I am not sure of your experience or industry but while it is true customers/users don’t see code, they most *certainly* see documentation.
In the form of “help->about” or user manuals, websites, or call center interaction.
When I said “documentation is important” I meant all documentation and sometimes an engineer needs to document across scope boundaries. (IE: you should be able to describe where that file export api fits into the grand scheme in a way that gives a user what they -need- to know or gives support advice on how to fix issues.)
Both, in my opinion. From incipient need (rfc, etc) to use-cases, to design specifications, tolerance acceptances, expectation management, support, and finally sunset/archival.
If the code is where the “why” is found, those who are the end goal consumers of the product will be frustrated, for a small example.
> Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more
Strong disagree. If you haven't found an issue with something you love, or a useful aspect in something you hate, you need to experience more. I don't know if I'm senior other than doing this for a while, but I had more opinions when I was starting out than now. I do have more clear opinions now in terms of being able to say why something is important. But a great number of things (statement vague on purpose) people have strong opinions about are not really important.
I totally get what you say and respect it but I can also understand what the author means by saying that. Perhaps he did it in a very radical/too opinionated manner. Let me explain: When I am interviewing someone, I also like to ask about opinions on tooling they like/use. For example, the person I am interviewing has on his/her CV that has plenty of experience with Terraform (or I can infer it from the work experience section). One question I would ask is: What do you find good and bad about it? This helps me to get a clue about the reasoning process of the person (e.g "This person uses this tool blindly because is the mainstream thing to do" or "that decision came from a more or less rational analysis and has made the exercise of considering the flaws"). I value this because personally, I want people that can understand the consequences of a technical decision, not fanboys that learnt how to use a hammer at some point and
never asked themselves if a hammer is the right thing to use (or even if they are using it right).
I think you are correct in the approach to see if the individual themselves, on a case by case basis, can give well thought out reasons for their choices.
But there can be a lot of fatigue in software process and tool selection, because it can be so opinionated and change from year to year quickly. I think it's the lack of good scientific studies of processes, and the immense difficulty of constructing such a study, which often leads "the best way" of doing something, to be based on personal opinions and sometimes, whatever is popular in the community at the moment.
Sometimes I think that the quality of a product, really only depends on the quality of the individuals making it, tools are just a means to achieve the goal, as they can be made malable. But I digress, it's not so simple.
Totally agreed. I just decided for my own sanity that some things just aren't worth arguing about. Obviously I have opinions on my tools, but I'm not going to force my preferences on others, or spend energy endlessly debating those preferences. Work is enough mental load as is.
In my experience, strong opinions about details tend to derail conversations, drain energy out of a group and just make things more difficult than they need to be.
At work they use a lot of tools that have better alternatives, or alternatives that I prefer, but I choose to work with what I have and just get shit done.
> I just decided for my own sanity that some things just aren't worth arguing about.
Yep, I was raised to question and then argue everything with passion. It’s a waste of time. Mostly people will say they agree just to make you stop wasting time; they won’t be convinced (even if you are right). I want all that wasted time back now that I’m older. I don’t need people to agree with me on everything, or actually hardly anything. And when it’s worth going to battle, you can in those rare cases.
I'm not a parent but that sounds like parenting on hard mode.
And I couldn't agree more - because I don't argue over every little thing, I feel like my opinions are more respected and heard when I do. (Or maybe that's just a projection of how I respond to others.)
I think you misinterpret that: your stance is clearly having an opinion about that matter.
The author is worried if you just shrug and cannot give any opinion or reasoning (which can be "this is unimportant vs the grand scheme so I dont care much about that here, but xyz more") and I would agree there.
On the other hand, with many things which I had initial frustrations about and I always assumed it's because of something I don't know and certainly there must be a reason why it's popular so I didn't want to express opinions about it and let it go, because I didn't want to seem like an ignorant person ranting about something they don't know how to use, I have developed stronger and more hateful opinions about now that I have years of experience and confidence. And then I think many who use those tools have this Stockholm syndrome type of thing happening where they try to justify why something is bad.
Yeah. While there are tools and design approaches I disagree with, I do think that for the most part most stuff kind of works, and the differences aren't actually that great between good-enough and optimal. Worrying too much about these things is the sort of majoring-in-the-minors I expect from inexperienced developers.
I'm much more worried about building something interesting than building something with interesting technology.
I can confirm. I found out that people who have "violently" strong opinions on how one tool is much worst are the ones who ... did not actually tried the other tool. In our company, people who never worked with Eclipse need to pick on it constantly, I dont know why.
People who actually switched from one to another (some forever some for at some time) are waaaay calmer in their opinions.
I interpreted this as the author saying that a senior dev will have "found an issue with something [they] love, or a useful aspect in something [they] hate..." "in a myriad of ways." I.e. I think the author agrees with you.
I have the feeling that code is becoming less and less important. In my day to day job as a SWE, coding is the easy part. There are tons of other things to do besides coding, service maintenance, discussing priorities and trade-off, helping users, fixing perf issues, code review, oncalls, tweaking configurations, understanding poorly-documented API and other systems.
Maybe I'm getting old, but it seems there are more and more things to know. Sometimes it's overwhelming and the constant context switching is killing me.
This is your experience showing; when you start out, the programming language and coding is everything, favorite activity, and you consider it the most important thing.
But over the years, as you get more experience and responsibilities, learn more tools and languages, you realize it's only one aspect of software development.
The overwhelming and context switching is a Problem in our industry I think, and it's perpetuated by concepts like devops and full-stack developers. Sure, some parts of your responsibilities only take up a percentage of time, and it's not worth hiring someone full-time for. But trying to make everyone know everything within a team is wasteful and putting a lot of pressure on them. It's pushing people to become jack of all trades, master of none.
Same here. First few years of being a SWE I had all the romantic notions of working late in some dimly lit office with a packed war room of developers, slamming Red Bulls at 3am while you're all trying to figure out some bizarre bug that keeps crashing your web app. I had a lot of those late night sessions and major releases that you go home at 6am and are expected to be back in the office by lunch.
Lately, its the same thing for me. Very little coding and actually building stuff. Its mentoring, meetings, fixing broken API endpoints or bug fixes that have lingered through multiple releases and keep getting shelved. I'm not sure if I've just lost my passion for coding, but it doesn't feel like I do much coding any more at all.
And sometimes you’re no master painter and don’t want to be one, you instead focus on the what and figure out the how by trying things out. You eventually learn tehnique along the way…
This is one of the best pieces of advice in the article:
> You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people.
And it's one I wish I'd kept in mind for a lot of personal projects in my life. I love designing stuff up front and implementing things based on that, but often that's led to sticking with ideas that didn't actually pan out the way I expected them to, especially when it comes to game design/development. A lot of the time, a good level or game or boss fight or whatever is completely different to what you initially imagined it would be, and you should be willing to change direction to fit the bill.
> Sometimes you have to stop sharpening the saw, and just start cutting shit
Also this one for much the same reason. Overplanning for things is a curse, especially when said plan hasn't quite come into contact with reality.
It should be taught how to "size" your planning / iterating balance.
Few years ago I made a tiny vue app (to learn that lib) and every time I though adding a feature would go one way, it went another, and made me see things I didn't perceive about the app structure.
At first it felt frustrating but if you size features on the smaller side (~agile spirit) and change your spirit it becomes a new kind of pleasurable skill in itself.
It also impacts how you write code, because you anticipate a bit the potential refactorings now. So you tend to become very frugal and efficient in how you code and how you abstract. Which another pleasurable skill.
Something no moonshot side project ever taught me.
> And it's one I wish I'd kept in mind for a lot of personal projects in my life.
It's one thing I'm currently doing, and I'm quite happy about it: I always wanted to have a project that could "grow" with me, but never had an idea. Turns out I already have that: My personal website is running on an engine I wrote myself, basically just turning a directory into a website (like Directory Listing from Apache, but more powerful). I'm currently in the process of refactoring it. Eventually, I'd like to host it on GitHub. :)
The fewer people you have to answer to or debate with, the better. If it's just you and an artist making a game, your job is just to convince the artist why you need to change that level boss. It's a lot easier for a few creative people to make a good decision that they're comfortable committing time to than it is for them to have that decision rammed down their throat by a corporate hierarchy that doesn't actually touch any art or code.
> 4. The best code is no code, or code you don’t have to maintain
Relativised in the last sentence:
> This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.
Rubs me the wrong way. I get what he is saying here. But damn this feels outdated to me coming from web development.
I work in a small web dev team, but we're constantly working hard to reduce dependencies and rather code things up ourselves. We have designed it, we know how it works, what it can do and what it can't. We have tested it, we maintain it. It is smaller and more purposeful and fits our needs well.
Just keep in mind that this is a learning process.
You will likely suck at writing your own libraries and tools until you made some mistakes. But the end result is code that does exactly what it needs to instead of something that is cobbled together, hard to debug, hard to change.
When your code breaks you can debug the code in your head, while you are walking your dog or after you woke up from a nap. You can see it all there, you can _feel_ it.
With external tools, services and libraries it's not like that. It's always a black box. And it might suddenly change its contents if you look at it funny.
To add onto this, I'm growing more and more skeptical of auto-generation. I understand how it theoretically helps, but the issue is I now have to learn yet another proprietary language to configure the auto-generator (which I then forget because it doesn't get touched often), and when something goes wrong we can't just fix the type and move on, we have to reregenerate the whole module, often with flaky eclipse plugins that require their own arduous "get it working" procedure.
Yes typing mundane things manually is a bore and subject to human error, but that's what code reviews and testing are supposed to be for. It's possible my company's just doing it wrong, but I've definitely had the experience where by the time I got the auto-generator doing what I wanted I could have just written the service/classes myself without piling on extra arcane technical knowledge that I use maybe three times a year.
Very good general point. But I would add the caveat that generating code in a data driven way from a standardized format is fine. You change the data and re-generate the code, fix the calling code if need be.
Also I think it depends a bit on the language and what exactly you generate. If you generate concrete types (or classes) then that might lead to more fixing and refactoring down the line. If you generate data it's different, because you are going to have a general interpreter for said data that doesn't care about its concrete shape.
I said it before: coders import libraries, engineers import dependencies.
Not having to maintain code you depends on means someone else is maintaining it (or not!). That makes this person a stakeholder in your project. It also means that the functionalities your project is relying on might get deprecated tomorrow morning. Then what? Fork and maintain yourself?
> Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software..... You need to explore other languages, libraries, and paradigms.
Funny. I've used a wide range of things in my career and if anything, it's made me less opinionated, not more. There's something that sucks about everything, and usually the part that sucks is slightly different, so... why should I be so opinionated about what I'm using? It all sucks in slightly different ways anyways.
The way I interpreted that point is basically "if you don't think the tool/language/library you're using sucks in some way, you're not using it enough". As in, "opinionated" here doesn't mean "you should use this, everything else sucks" (which is what opinionated usually means in software contexts), it means you have opinions about these things that are founded in experience, not impressions. In that light, you ARE opinionated.
For instance, I am opinionated... but I keep my opinions to my own (e.g., personal projects). When working with others I'm less likely to be like that because, well, everything is more subjective than it seems. From my point of view, there is nothing more junior than being fixated with the idea that tool X is the only tool for job Y.
Sharks also evolve. There were sharks 400M years ago, but they weren't the sharks of today. Some core banking app written in the 70s and still running today on a mainframe that requires software and hardware emulation of a 1970s mainframe is probably a dinosaur.
Something like unix that sprang up in the 70s on the same types of mainframes and has evolved and changed a lot over time but still kept a lot of core conceptual DNA is probably a shark.
[1] in the form of neovim and vim in particular, but also nvi, busybox vi, and probably others.
[2] i just got a box from dell that has only one non-network way to interface with it: serial over usb. I had to remember how to set up my line parameters etc. Fun fact about xterm, etc: many of them allow you to do `xterm -l /dev/ttyUSB0 115200` way easier than dealing with picocom or whatever
I like the Sharks not Dinosaurs thing. i keep see people saying "the FAA system was so old"... being old wasn't the problem, lack of maintenance is the problem. We have roads that are old, bridges that are old, buildings that are old, planes that are old, ships that are old, that still do extremely well.
Rewriting COBOL in Javascript is not going to make a system more reliable. Making a system reliable is what makes it more reliable.
Rewriting COBOL in javascript would make the codebase accessible to a larger pool of potential engineers who are also more likely to be up-to-date on best practices (as opposed to an engineer that has stagnated in COBOL for 30 years.)
I'm not sure a rewrite is warranted, but a system isn't maintainable if there aren't enough people trained in the particular language / tech stack.
I think conditional probability of a Javascript programmer knowing best engineering practices is so much lower than that of a COBOL programmer, due to large numbers of unqualified Javascript programmers, and much higher average experience of COBOL programmers.
oh please no JavaScript- it is awful enough in the frontend, but that train seems to have left the station, but in the backend we have much more powerful languages and ecosystems.
A fantastic list. And frankly the bit about context should be thing number 0. Context matters throughout everything you do in a system.
So many "tech wars" come down to "you are both right in a different context." Holding a dogmatic view that "we should always do X" is usually detrimental (for some values of X).
I like people to have opinions, and to make suggestions, but I tend to take more seriously those who can discuss the downsides as well as the upsides.
For example, a junior I have tells me we need to switch to tool X. He lists 10 benefits of doing so. It's obvious. We're morons for not having done it already. Clearly we're incompetent pointy-haired managers getting in the way of real programmers.
I ask him to argue the opposing point of view - why we _shouldn't_ change. Sometimes the quick answer is "there is no reason". But what I'm looking for is an acknowledgement of the impact of the change. The costs of retraining staff. The existance of existing code. The pushback from others. Etc
Only by understanding both sides can something be recommended.
I see juniors have this issue more than seniors. Seniors tend to understand that change causes ripples, and there are positives and negatives to everything.
Change is necessary. But jumping on every new thing can be disastrous.
Clearly my point works in my context, it may be different in yours.
Overall nice post. But the point 5, irks me the wrong way. Every time I read something along the lines of that paragraphs, something inside of me dies.
At expense of being downvoted to hell. I'm gonna say it in caps to emphasize, not to shout:
IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE.
This doesn't apply to all Software Engineers (like the one who sells the product is also the Software Engineer, or writing open source libs to other developers, some freelancer,...).
It makes me sad to see how many Software Engineer are brainwashed to put up with the stress of producing value.
When people like PG, DDH or you name another CEO/Cofounder, say: ultimately we should produce value. They are not talking as a Software Engineer, they are talking as people who owns and sell products/service, who happen to be the Software Engineer of the product/service.
I, as employee Software Engineer who produce software that other people use and a sell, must not be concerned about the value of the product/service. My only concern is to design and implement what they ask for. Whether what they ask for as any value, it is not my responsibility. It is their money, they should find value in what they asking from me.
Why? Ask yourself if you are ultimately participating or have any say in the pricing of the product/service? Or do I sell the product/service myself? If you answered to No to both, then it is not your job to produce value.
I hope in the coming years we reduce the stress we put on Software Engineer. In the last years, I keep seeing this trend of making Software Engineer to everything.
> My only concern is to design and implement what they ask for. Whether what they ask for has any value, it is not my responsibility.
You're describing a compiler. You are not a compiler; you are a software engineer.
You will, especially as you get more senior, be asked for things that are wrong. You will be asked for things in the form of a fuzzy problem statement with no direct guidance on what to change, with the understanding that you will talk to relevant people and figure out what needs doing, and then you'll build that. One day, your job will be to figure out, with no prompting whatsoever, what things need to be built, and you'll build those things.
Your job isn't "to create value," but it's not "build the thing as described without questioning it" either. That's a compiler.
My problem though, is that 95% of the time, the people doing the asking aren’t competent to do the asking. It’s not just about bad market directions: “You wanted a plaid Cadillac, I painted you a plaid Cadillac.” Often, the people doing the high level directing are there because of the Peter principle. Now it’s a bit more like being a pilot or a train engineer, you’re doing the hands on implementing, but the charted course is not just inefficient, it does lasting damage to the viability of the vehicle. And when it’s all bolloxed, it’s you, your peers, and your profession that take the blunt of the blame. The very thing that got you collectively into the mess—their inability to really understand what they’re doing—is the thing that saves them.
So in an idealized world, I totally agree with you. When I have the pleasure of being healthily remunerated to craft solutions under someone else who has respectable experience and wisdom about software choices, and owns both their success and their failure and insulates me from that, I will happily move past tue sense of responsibility that inevitably works it’s way into what I do.
I understand and I agree with you. Mine is an idealized world, I know it. By the way, spot on with Peter principle, that's one of the main reason, all this producing value makes me go crazy.
I'm sorry. As a former software engineer and now CTO I have to disagree completely.
Adding value is everyone's responsibility and the product/business/pricing ideas that come from engineering can be as valuable and influential to a business strategy as those from the CEO or PO.
If you want to write software that isn't rooted in building business value you should be an academic or hobbyist but in any well run business that depends upon or sells software /SaaS services, engineering should be a critical influence on the business's strategy.
If an engineer is just a cog in the machine and doesn't get or care about what they are building, who it's for, and how it changes experience and increases shareholder value then how can they take a wider appreciation of their work and its impact on the real world?
Agree with you. Have been a software engineer myself for 20 years (and also had, in the past, studied a lot of design and process books in my free time). Yeah, I also think this person's comment is not right. In fact, the second and third points in the list ("the hardest parts of the system are building the right thing," and "The best software engineers think like designers") are directly addressing the fact that devs first need to figure out what to build before they even write any code.
Yeah, in fact, one big tweak I'd make to this list is on item #17 ("Keep your processes as lean as possible"). Yes, it should be extremely lean, but the requirements phase should be a necessity for all development. One of the first steps in development should be a thorough collection of info on the task at hand: talk to the users, the business people, the former engineers, and anyone else that has any connection to the change you're about to make. You'll solve dozens of problems before you even write a single line of code.
Yeah, agile overall is how we should work, but personally, think requirements is the one step that needs to be emphasized and even defined in greater detail. I know this doesn't directly tie to "adding value" but solving the correct problem for your business almost always adds value.
I never said we should not be adding value. I, as Software Engineer, add value. I write the software ultimately. Whether that software has value for you CTO, CEO or whoever own the software, cannot be my responsibility right?
My problem is that seeing value in a software product/service is dictated by the vision of the company and the market. The vision for a product is not a cog's responsibility.
To make an example. If all the engineers of Tesla were asked to build a car, not from Elon, but someone else who didn't see value in EV. What would've happened? I don't think the engineers would come up with an EV. The value is create by you CEO, CTO and owners of the product. If Tesla with Elon had failed, is the engineers responsibility to not have produced value? The vision was wrong, simple. Heck, how many Apple/Microsoft products didn't take off and don't tell me they were badly engineered, that can't be the only reason, or the engineer didn't produce value.
Wether I write software rooted in business value or has an impact in real world is a moral decision, right? And I think we can both agree that morality has nothing to do with value of a product/service. Example, military weapons. I would not morally do it, but there is value in it right? Who dictates the value of it?
If a shareholder invest money in something, it is because they see value in it, right? Or they invest blindly and expect engineers to create value?
I think I can see where you're coming from (we engineers are implementers, and not in charge of the vision for the product, which is mostly true). But yeah, I still disagree with your point overall.
In my humble opinion, as engineers, it is still our responsibility to deliver value to the CTO/CEO and the company overall. Because engineers have the best understanding of the system, and often are the best counterpart to the business people. We guide them on what is and isn't possible, and even more than that, we often understand the business domain nearly as well as they do (from a more technical aspect).
Just off the top of my head, I worked at a US eCommerce company that was trying to open their site to new markets in Europe. The business people designed a flawed payment system because they had a poor understanding of how payments worked. A coworker of mine realized what they had done was wrong and would cost the company hundred's of thousands if it was used, and worked with the business people to rework it (see below for more info). He didn't simply follow what tasks he was given, he saw that he needed to step in and help them pick a better solution.
In the end, the goal of the job is to do work that improves the system and benefits the company. You could just focus on just being a great implementer (the ultimate hammer), but to me, this is not how a true software engineer thinks, but maybe how a lower level dev might work.
... And, the problem my coworker worked on was this: the business people decided if anything went wrong with payments in a foreign currency, the system would default to US dollars. This is a bad idea, because this will create enormous accounting headaches and greatly complicate the system. The best solution is surprisingly to let it fail. Yeah, if there is an error in a payment's currency, something is seriously wrong and we need to know about it.
I don't know. Something must be wrong with the way I think.
In your eCommerce example, what is the product/service? The payment system? Is the payment system A? Or payment is B? All these answers are wrong. The product/service is "make the eCommerce for Europe". That service should have value, how is that "bringing to Europe" value a software engineer's responsibility? In order to materialize the "eCommerce Europe" we need a payment system. Now comes the role of the software engineer: design, propose payments systems. A payment system has nothing to do with the value of the product.
My responsibility is to provide a correct, within the specs, payment system. In your example, the first solution is not acceptable (I don't even consider it a solution).
Now suppose you shipped the "eCommerce Europe" with correct payment system. But the product/service "eCommerce Europe" didn't take off as in US. Didn't the Software Engineer produce value? It doesn't make sense to me. The Software Engineer produced the value: designed, developed, tested and shipped the payment system. Thats the value of a software engineer.
If you can point to the requirements you were given, the technical clarifications you sought, etc. and show how you fulfilled them, then you as a SWE did your job. If you happen to have the domain knowledge to challenge the whole thing on principle, that's great - but that's something that should happen before it hits your desk.
I recently got a haircut. It was exactly what I asked for, but it doesn't suit me at all. I tipped my hairdresser (who is great, and I should have paid attention when she said "really?") well, as usual, because it's not her fault I asked for something stupid. Could she have pushed back harder? Sure, but that's not really her job and it would be unfair to blame her for not doing so.
The point is not to just say: "Hey man, I did my job and built what you wanted. It's on you if you asked me to build the wrong shit". While this technically might be 100% correct, in terms of roles and responsibilities in the firm; it is ultimately (a) unhelpful to the business's agenda and (b) not really focused on adding real customer value. Yeah, you did your job, great! But we're still fucked.
If you were wanting to add true value you should, IMHO, be saying "Hold on a moment there, buddy, you are asking me to build the wrong shit -- have you thought about this? what about if we do that? surely this is a better/safer/more effective way?"
All good business/product people I know love it when engineering comes forward with this kinda stuff. It's what separates the good from the great. If you are working in an environment where the CxO, PO, sales guy tells you to "fuck off and just code what you've been told to" the you are so in the wrong job and you need to get a new one. Fast.
Why we are moving the goal post? The problem was not building something right or wrong. The problem is building/producing/delivering something of value. A lot fo wrong things have immense value, and the opposite is also true. How should I know if the thing I'm building has any value in the target market and it aligns with vision of the company? Is it my job to do market research or to build the thing asked for?
To make the point clear, I'm gonna make an extreme example.
If some one asked me to build the next social media to a poor country, where the immediate problem for 80% of the population is to find stable source of food and a shelter, and I'm payed to do so. What should I do? If I don't have the knowledge, as software engineer (which is almost always the case, i.e. not knowing a lot of the business decisions), about the target market, what should I do? Now, as software engineer, should I also do market research? How, I'm gonna know all the business decision about a product? Maybe the people commissioning me the engineer side of the business have already some client ready to buy? How am I supposed to know the business strategy? This is absurd. This is again putting everything on the shoulder of software engineers.
It is unhelpful, as you correctly say it. I don't denied that. But you should not deny that finding product that have any value for business agenda, is a role a market researcher should do, or someone else more competent in that area.
The fact the reality is how you say it is, it is sad story. But that doesn't make any less unfair. I did a B.Sc in Computer Science and nobody thought me anything about business, product, market research, pricing techniques. I don't how to do it properly nor I can guarantee that the product I'm building for you have any value in whichever market you are going to sell it. And I'm not comfortable taking that kind of responsibility. It is unfair and dishonest for both the buisiness and me.
In my opinion, we're kind of just going in circles. Yes, we as engineers don't have a full understanding the "overall" and "high-level" value of the work we do. 100% true. But, our value is at a smaller level. Is the feature we created going to meet the project's (and the company's) goals or not? (as we understand them)
Requirements gathering has always been apart of software engineering, and actually, we're usually a necessary part of creating that spec. As we all know, a business person has a vague idea of what they want and they work with a technical person to see if this possible or even a good idea). We try to create the right solution given our understanding of the goals of the project and feature. The value again is smaller.
...Although, I do see your point, it can be easy as the technical expert to start giving opinions on things that aren't your responsibility (like marketing strategy). Maybe you've gotten hit by this before? (this is always touchy subject, but I've definitely been scapegoated for problems in the past, never fun). But still, typically, tend to find that the business person is ultimately in charge of the business decisions and I'm responsible for the technical ones.
.. oh, and just to add one more thing, seems like the higher you go, the more of a business person you become anyways. Because for most decisions, the technical and business aspects go hand in hand - should we implement a new payment system in Europe? If we do, how long do we think it will take? Or is it even feasible? If we it is, will it work in all European countries? Will it be easy to maintain?
The business person often has little idea on any technical estimates, but these are crucial to making an informed decision. We work together with them to come up with our best belief on whether the idea is worthwhile.
And agreed, it is a lot of responsibility, but again, it's only when an engineer rises in their company.
Nice example, thank you. Worst when the hairdresser change the style throughout the process because they think something else is better for my head. Maybe at the end I go home sad and frustrated, because (a) I didn't get the style I asked for (b) the one I got does'n fit my face and worsen my value and (c) I had to pay too.
> I, as Software Engineer, add value. I write the software ultimately.
Yeah, but if you wrote the wrong software (maybe because the PO specified the wrong thing and it wasn't your fault) -- did you still add value? No, you burned story points for no upside at all.
As I said in another comment. You people keep moving the goal post. If I produce wrong software, it is my fault I agree. But I can still produce correct software without any value. Should I be at fault to producing something you asked for but that doesn't have any value in market?
The problem is putting the pressure on software engineers on producing software that has value. This need other competency that the business should study and plan properly. It is not just a software engineering thing.
> IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE.
Says who? Is there a law that forbids it?
If companies where SEs are focusing on value are more successful, then naturally it becomes SE responsibility.
> My only concern is to design and implement what they ask for
What they ask for changes over time. The hardest part of SE is not building first version of the software, it's evolving it. If you don't understand where the value is coming from, you will always make wrong predictions. Given freedom, you will always choose to focus on things that matter to you (performance, scalability, fancy tech, etc) instead of things that matter for the business (growth, UX, features).
Forgive me, but this is a non-sensical question. I can ask you the same. Who says I should deliver product that has value? Is there a law for that?
Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not? Why we have UI Designer an UX Designer? Shouldn't we call them all just Software Engineering? You clearly see which metric matters to a software engineers (performance, scalability...) and yet you say the software engineer should not do that and just do something else (UX, growth...) ? And who should think about performance, scalability...? The UI Designer, I think, right?
And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that? I guess only the software engineers should worry about that, on top making architectural decision. And the CEO who runs and has vision for the product, what should they do?
> Who says I should deliver product that has value?
Whoever hired you?
"Not my responsibility/problem" is a terrible attitude, nobody wants employ those people. They can be useful as contractors. But if you are hired as an FTE, it's strange to complain about not being treated as a contractor, don't you think?
> Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not?
It's a false dichotomy, all of those are Software Engineering. Some of those are not Computer Science, but could still be strongly tied to it (e.g. UX is often a synonym for HCI).
> You clearly see which metric matters to a software engineers (performance, scalability...)
No, I see this is a metric that matters for bad software engineers.
> And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that?
Few people should be responsible, but everyone should think, plan and provide feedback.
What you need to recognize is that engineers are in unique position: they can understand 80% of business domain, while business folks can understand 5% of engineering domain. You'd be an idiot not to involve engineers in delivering value.
That's fair enough if it is clearly stated in the contract. If it is a silent assumption, that's not gonna work with me. It might be a bad attitude in the eye of the client, that's fine with me. I avoid those type of work anyway.
> No, I see this is a metric that matters for bad software engineers.
Well, this is a matter of opinion I guess. Not gonna argue with opinions, everybody is entitled to one. To give you my perspective, I think that is the sign of a good software engineer. He knows his role and what he studied for and focus on that. I don't want a half assed software engineer who doesn't know anything about business decision to make value judgment on a product. At least, I would not do it as a software engineer, is unfair and dishonest for both.
> Few people should be responsible, but everyone should think, plan and provide feedback.
Yes, everybody should participate in what they have competence of. As I'm never gonna argue with a UX/UI disegner about stylistic choices (accesibility, trends..? I don't know anything about that), I'm not gonna provide feedback on the value of a product. Hey, at the end everybody is free to do whatever they wish to and reap/face the consequences of it. It is just, I feel it is unfair to expect things from people for which they didn't spent year and money to study and blame them if something goes wrong.
> You'd be an idiot not to involve engineers in delivering value.
Yeah this is the mindset of the shareholder, who invest and try to extract as much as he can from a few individuals. I understand.
> I feel it is unfair to expect things from people for which they didn't spent year and money to study
Studies are always falling behind real world needs.
Also, your words could be rephrased as "I don't expect to learn at work".
> this is the mindset of the shareholder, who invest and try to extract as much as he can from a few individuals
Or a mindset of an engineer that wants a higher salary. You seem to recognize that shareholders have a demand for those types of engineers. And trust me, the supply is extremely scarce.
> Studies are always falling behind real world needs.
That's very very true. Not gonna deny that.
> Also, your words could be rephrased as "I don't expect to learn at work".
I like to learn technical things. Studing whether Mary like red button or green, I don't find it appealing. Likewise, I don't like to see where or who is gonna use my product. I know, a lot of people "hate" this attitude. But, I know where I'm good and where I'm less stressed yet still provide engineering service for my salary :).
> Or a mindset of an engineer that wants a higher salary. You seem to recognize that shareholders have a demand for those types of engineers. And trust me, the supply is extremely scarce.
I know, but this is my experience. I value more free time. Money should be just enough to sustain my lifestyle. And doing all thing not related to software engineering takes more time and leave unhappy. That's just me. And I just hope people don't silenty expect more from me and then be unsatisfied.
We've gone from "IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE" to "As a software engineer I like/prefer/value other things". I'm not going to challenge your preferences as long as you don't enforce them on the whole industry.
I knew that phrase in caps would bite me at the end. I studied comp sci because I liked the field and expected that in my job I would learn and expand my knowledge about it. But the reality was completely opposite of all my expectation. The whole industry wanted me to provide service for things I was not prepared nor have an innate attitude/willingness/mindset to grasp and formulate a valuable opinion that other people can use without disappointment. It is hard for me to see disappointment from clients when they expected something I don't have the competency to provide. As software engineer I like to build things independently from their value in the market.
There's a lot to like here, but, as with almost all 'advice' lists, the author makes the mistake of believing their own hype. They're effectively saying "I am a good developer, I do these things, therefore to be a good developer you should also do these things." It ignores the possibility that there are good developers who don't do those things.
An example is the advice that "Software engineers should write regularly." Why? Can't you be an awesome dev if you don't write? You definitely can, because I've met hundreds of great devs who've never written anything that you'd call 'writing'. Devs who enjoy writing, and get something from writing, should absolutely write things. If you're a dev who doesn't enjoy writing then you probably shouldn't force yourself to do it just because someone said it's what devs should do. Find a different outlet that gives you the same thing other people get from writing.
I’d definitely agree that “software engineers should publish writing regularly” might be off the mark, but “software engineers should be able to write well” is pretty uncontroversial. And being able to write well comes from focused practice, however you get that practice.
One "easy" way of "writing" is to answer support emails / calls. It is almost the same as teaching stuff, only with a more relaxed timeline. I am currently supporting a system (and have been supporting other such systems in the past) about which I know very little. So each time a support request comes in I have to dig, understand, formulate an answer, scrap it, dig again deeper, ask around, etc.
In the end I don't even care if this takes a lot of time, I learn so much in the process that it is absolutely worth it. I would not be happy doing it 100% though, because writing code is really on a different level, but I find that these two complement each other very well.
Corellation is indeed not causation and humans are good at finding patterns where there are none. He might also drink a strawberry milkshake each monday, or pray to the arcane, binary gods before going to work.
However it is okay if someone says: "Writing helped me as a developer. It might be different for you."
Hopping that easily from "works for me" to "must work for everybody else" without a second thought is indeed not reassuring coming from a software engineer where "works for me" is not enough.
Touching on the writing point. Think of it as muscle memory, if you watch people put together PowerPoint slides you see that those who do it regularly can create a solid presentation quickly. As a developer, at some point you're going to be writing some basic technical specifications to decompose a project. Even if you've been only writing to yourself, having the ability to quickly pull together a document that communicates with others is an asset.
I'm nitpicking now, but it's not necessarily "this worked for me ergo do this" – it could also be a sprinkle of "the other skilled software developers I've observed have also done this". It's not much less anecdotal, but it does shift the perspective from "this is what I do" to "this is what I think matters for other people as well, based on my limited observations".
Sometimes a pattern of an individual's learning beliefs about X ends up something like this path over time:
1. X? I don't know anything about X.
2. X is TRUE.
3. X is FALSE!!! (How silly to think it was TRUE! I'm on a higher plane of existence now!)
4. X is generally TRUE, but with caveats Y and Z.
5. X seems less relevant than P, Q, and R.
6. Better understanding of P, R, T, and V. But Q doesn't seem as important as it used to.
At each step of understanding evolution, someone at an earlier step of belief evolution probably seems less enlightened.
And someone at a later step, along the same path, might also seem less enlightened. (Unless you have an opportunity to understand their thinking, and choose to take it, and are able to understand it.)
I love the idea of technological sharks roaming the software oceans. I've seen a few megalodons hanging around the mainframes too. Thanks for sharing a great list.
I think the less code the better is the aim but it is harder.
This does not mean grab some massive framework, like Django, where you can write 10 lines and you have a whole application. It means taking a the time and care to keep things as small as possible from top to bottom.
It reminds me of the quote "I have made this longer than usual because I have not had time to make it shorter. "
It is hard to make things simpler. It takes longer to code and, in the end it looks like you have produced less code. This is where the 10X developers come from.
As for the whole 10x programmer debacle... well it all depends really.
Are there people who are better at programming in general? Sure. But there are also plenty of people who just seem like that because the company they work for demands less than their full expertise.
The same dev who's a '1x dev' at Google or Facebook or Apple might be a '10x dev' at a small web development agency, and a '100x dev' at a business which doesn't specialise in software engineering at all. And the same goes in reverse. Point is, the environment and how well your practices gel with those of the team/company have a huge effect on how productive you are, as do numerous other factors. It's basically the whole 'nature vs nurture' thing really, and both aspects play a role in how skilled a dev anyone is.
This hits so close home, I need to know if the author is a former colleague :)
I agree especially with two points: no one asks “why” enough, and the best software is the one that does not need to be written. Both often conflate as “we wrote it because we didn’t know we shouldn’t have”. I have lost count of how many times we asked “why”, just to find out that some engineer was having such a good time writing software that she ended up creating and integrating a shittier version of a widely known tool.
Check, check, check, yep, all the points are well taken.
There is an OCD critter inside every developer trying to break free.
We, developers, are stuck withing a rock (hardware) and a hard place (business).
In my years coding (mostly C) I started paying less attention to code
and more attention to people, their endeavors and motivations.
It's the whole package.
I must say.
The point about innovation really struck a chord with me. I think most people really hate fundamental change which makes life more difficult.
However, users do like convenience: if you make something that is quite onerous to do, but the new method proposed is much simpler, has fewer physical steps to perform etc., they do tend to adopt it.
Which makes me wonder about the whole OTP thing...
> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
On the contrary. The more senior I get, the weaker my initial assumptions about everything becomes. The more I know, the less I know (so the less I push my ideas into other's people's minds)
To me, it's simply: It's easier, simpler 100x to manage 10 small services, than a service with 10 functionalities. Main reason is, i can easily swap out, replace any small service with better one. With big service, it's impossible !
So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.
Dividing your work up in to modules is sound advice.
What blows my mind as a non web developer, is that when people talk about micro services they connect these modules not using a function call, but as a HTTPS request over a network to a different machine!! The orders of magnitude of latency / performance / hardware / energy / bandwidth wasted establishing a connection to a remote machine using a text based protocol, vs a native C API call is mind boggling to me.
I don't understand how you can say this with a straight face, especially "100x". Operationally, multiple services is always more complex.
Unless there is something unique about the setup (E.g. one piece of functionality requires much higher scale, make sense for the domain, etc) it doesn't make sense to split things into independent services.
This sounds like a microservice vs monolith statement in disguise.
Respectfully I disagree, maybe with more context I’d be on a similar boat.
The communication overhead is a real challenge to be reckoned with. I don’t think the mere fact something has 10 functions in one service makes it better or worse than breaking those out into their own services (not even getting into at what level do you break them down? Since most all code is a composition of functions)
Personally I go monolith first, then if and only if there’s a function of the monolith that needs to scale separately from the rest of its parts, then I’ll consider making it its own service (and this has to be a pretty large extreme to take on this burden)
Too many times I’ve been burnt by attempts at micro services, which seem to stagnate faster than monoliths at some companies. I also think there’s a higher degree of documentation each new service made, vs keeping it an endpoint in a monolith. But I digress
There's an in-between point that I think is more common than good microservices, that I think you're describing, that I've seen called a "distributed monolith". Basically what happens when the microservices are too intertwined to be independently replaceable as GP suggests.
Good learnings. But there’s obviously very different jobs out there all called “software engineering”. Here we’re looking at the (perhaps most common) type where the challenge is to understand what software to build. But there are certainly other types, and the learnings there can be almost the opposite I would say.
I hope I'm not misinterpreting the point 11. As somebody with nearly 20 years in the field I found that the least knowledgeable people will often have the strongest opinions. Later in the career they learn there are no silver bullets, everything has trade offs and become more open minded.
On the sharks vs dinosaurs topic, I’m curious how this applies to languages and if C++ is a shark or dinosaur. Of all the languages that seems to be one on people talk about as being on the edge of extinction (Rust, Carbon, Cpp2, etc.) but keeps on going.
What a great post! I could relate to most of the points. It is for sure one of the best articles I’ve read which covers this particular topic. Thanks Justin for putting in the time and effort for sharing your thoughts.
14y of experience, good 10x devs do exists, but they are extremely rare.
Everyone opinion is important, I learned there's not enough different point of views, edge cases missed...
> If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
I'm feeling like this is my next major skillset to improve. I've been building software for just over 6 years now and I can crank out a mean fullstack webapp in either JS/TS or Python, I can deploy it on a few various cloud infrastructure setups I've used (or just a VPS really), I can plug it into various databases or database services-as-apis, to the point that whatever problem a client could bring to me, I'm pretty confident I could answer with "yeah we can build that," and then do so.
But what I'm discovering is that there's a lot of things already built, and that if I can learn to simply deploy / integrate / zip together the right already-built things, the possibilities for the services and solutions I can offer on a timely basis increase dramatically. The problem is I'm completely overwhelmed by the equations necessary.
A few concrete examples:
1. A local chain of ~20 hot pot restaurants approached me and asked if I could build a membership loyalty app (會員卡 APP), with features that allowed for tracking membership loyalty across the various brands and restaurants they have to promote cross-business sales. Sure, I could build that in react native, customer accounts, simple phone authentication, plug into the taiwanese version of twilio, plug into, i dunno, airtable, whatever db as a service I want. But wait, they also want to eventually display the menu, have an admin app to manage menu items, ok now we're talking ecommerce / CMS. I mean I could build that out from scratch but shouldn't I instead try to plug in a headless ecommerce or CMS like medusajs or contentful? Well then I gotta deploy those, should I just get a VPS and throw them all on there? And what about the original member loyalty thing? Oh there's plugins for that, they just cost 90$/month, well fuck at this point maybe I should just buy a whitelabel restaurant POS system, then the only time I need to spend is in setup, then again, those are also expensive... but so is my time spent engineering whatever parts of this I need to do from scratch.
2. The local visa office is interested in a submission and display portal for immigrant stories here, something simple. They were considering submit.as as it's basically the exact featureset they need, but the pricing is a little... much. Shit, an anonymous submission CMS with admin publish features? How hard could that be? That's basically just a coding bootcamp project... right? Eh, imo it would probably take me a solid week or more to do something like that from scratch, or at least do it well, maybe I'm slow, but I decided instead to see if another platform could support that. Took me a weird amount of time looking at the bajillion CMS / blog implementations before I realized Drupal can do that pretty easily, but the hilarious thing is I only know about drupal as of a few months ago when I was looking into various CMS for the restaurant app thing.
Basically I went 6 years in my career taking designs from designers / executives and implementing them as new fresh codebases or in existing codebases. I've never really had the opportunity or projects where "wait, isn't this just a CMS?" or "can't we get these features by deploying an ERP and using the API it auto-generates?" were potential routes we could go down. Now that I'm touching that world, every time I start poking around, I'm totally overwhelmed.
I gotta admit I find it much more fun to be implementing custom SaaS or whatever else from scratch, I really haven't enjoyed spending hours comparing hosting prices and license fees vs my estimation for how much time it will take me to plug x open source ecommerce UI into z open source ERP on top of y VPS service (and do the server requirements match??).
Mostly I just wish I was better at doing the latter because well for one it'll let me pick up more gigs for my team cause we can apply ready-made solutions to a lot of people with the same problems, but also two because it's fuckin cool how much work people have put into a lot of these open source solutions and I'd love to use and contribute to them more (I've already had some PRs accepted on missing / incorrect deployment / installation docs, it feels nice).
Love the list just a shame to see the 10x myth. 10xers really do exist but it's hard to think about when framing it simply as 10x programmers.
These are people who see two levels of hierarchy requesting something for months and then builds a prototype over the weekend that solves 80% of the problem. Who sees two teams arguing for days back and forth and gets them together to make a decision with them and moves on. Who sees the hours wasted every day on bad tooling and bloat and makes the bold decision to cull and simplify. Who sees a product team losing a quarter building the wrong thing and is not afraid to shut it down with the boss. They know how to hire A players and raise the bar. They know when to hire. They know when to let people go.
They are not 10xers relative to 0.1xers, these are everyday 1xer situations.
They consistently have multiple magnitudes of impact. That's not easy. For most of us that happens a lot less.
There is this myth that there are no 10x engineers. This is categorically false. I was a 10x engineer when I was employed. I could do in a day what would take people weeks. It's an amalgamation of knowing the system, knowing how to try out ideas in isolation, knowing the editor well, a desire to build things fast and touch as few things as possible, aiming for simplicity and holding the big picture in the head.
So I think this myth is propagated by those who aren't 10x engineers and just want to give up before getting there.
I don't necessarily think his calling out no "real" 10x engineers is the main point of the statement. It's more that people who aren't good or are struggling to produce software are more numerous and should have more focus than trying to find a person who is outstanding. Which I think is a fair point of view. If I had to guess I think the distribution of engineers skews to having more poor engineers than great ones.
The problem with the "10x engineer" topic is: what is X?
How can you compare two engineers? Do you compare a junior against a senior? If you do compare two seniors, how do you make sure they are "comparable"? Perhaps they have different backgrounds (e.g., mathematician vs computer scientist) and one of them is so good at topic A, while the other is a genius at topic B.
I am a 10x engineer if you compare me with my junior colleagues. I have no idea how I do compare with my senior colleagues because they are good at things I'm not and the other way around: that's what makes a good team actually.
> So I think this myth is propagated by those who aren't 10x engineers and just want to give up before getting there.
In my area of responsibility and expertise I (as anyone else) can do stuff 10x times better and faster. I know patterns and a set of solutions that help me to do that.
But outside of that area I can be that <1x guy. Probably not 0.1x though, because of knowledge of meta-patterns common to wide spectrum of system designs, but still far from ideal ...
TL;DR:
Козьма Прутков: (ru) Каждый человек необходимо приносит пользу, будучи употреблен на своем месте.
Kozma Prutkoff: Each person necessarily benefits by being used in his place.
> In my area of responsibility and expertise I (as anyone else) can do stuff 10x times better and faster. I know patterns and a set of solutions that help me to do that.
Can you do it 10x better/faster than other people who are also experts in that area? If not then you aren't 10x.
A reasonable bar for 10x is that you should be much more effective than your peers in any codebase, even codebases they have spent years in. If that doesn't apply to you then you are just an average expert.
Edit: The best programmers takes the bus factor from 0 to 1, that makes them invaluable to many businesses. A programmer who can only do well using his own code, or who writes code that others can't work with, isn't very good at all.
> Can you do it 10x better/faster than other people who are also experts in that area?
Different people - different areas.
Like in Sciter[1] I've implemented HTML, CSS and script engines from ground up and by myself. If a task requires deep knowledge of browser internals from all sides then I think I can be of that 10x. Even among browser developers that do HTML/DOM or CSS or script engines.
It is not a secret that indie developers are in times more productive than teams that design analogous products. For many reasons.
I think you must compare like to like. Working on a team is always harder since you have to communicate the code you write, and you have to learn the code they write. Teams produce more value as a whole usually, but each individual produce less than if he was working on something on his own.
So comparing how effective you are when you work on your own projects to how effective others are when they work on a large team effort isn't a meaningful comparison. The most valuable programs are all huge collaborative efforts, so even if you as an individual produce less things you typically add more value by working on a big project, while most of the effort people put into their personal project never goes anywhere so ultimately provided 0 value, that is why we put up with teamwork.
But there are many cases where a team of collaborators just never gets anything done. I'm not sure how that happens, but in those cases any decent developer who has practiced some solo projects will easily do it in a fraction of the time. Maybe some developers just never builds their solo development skills and just practice the more lucrative team development skills? But you can't do without those solo dev skills, they are necessary to get out of those deadlocks where a bunch of team players all are waiting for someone else to fix a problem.
I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth.
Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them.
For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.