Things I’ve learned in my years as a software engineer (2021)

https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

by excsn • 4 years ago

557 251 4 years ago

emrah• 4 years ago

Kudos for the caveat that all advice is contextual

revskill3• 4 years ago

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.

creatorbytes• 4 years ago

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

Izkata• 4 years ago

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.

quelsolaar• 4 years ago

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.

nonethewiser• 4 years ago

Well generally they use RPC or GRPC

ZephyrBlu• 4 years ago

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.

revskill3• 4 years ago

It's a lesson for me, to have ability to maintain system in long term.

The cost with refactoring big legacy system is too high, to the impossible.

GuB-423• 4 years ago

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.

flandish5• 4 years ago

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.)

GuB-423• 4 years ago

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.

drbojingle• 4 years ago

Documentation describing whats already their and why, or documentation describing what's suppose to be there and why? Or both?

nailer3• 4 years ago

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

shepherdjerred• 4 years ago

I agree with this. When you're writing a program, start with your data structures. Your actual code will follow.

mmcconnell1618• 4 years ago

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.

neilv2• 4 years ago

"That ancient billing run batch process is an optimal killing machine!" (It might even outlast us through climate change.)

yodsanklai• 4 years ago

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.

Swizec• 4 years ago

A master painter can paint anything. Deciding what to paint is where they find the challenge and the fun.

First you focus on technique. Then you focus on the what.

grugagag• 4 years ago

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…

at-fates-hands• 4 years ago

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.

ip262• 4 years ago

Code is just as important as ever, but a two star general doesn’t carry a rifle either.

zethus• 4 years ago

This is an underrated analogy. I'm stealing this.

Cthulhu_2• 4 years ago

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.

fatneckbeard• 4 years ago

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.

nanidin• 4 years ago

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.

nlitened• 4 years ago

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.

verinus• 4 years ago

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.

neilv2• 4 years ago

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.)

agentultra2• 4 years ago

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.

kqr7• 4 years ago

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.

m_mueller3• 4 years ago

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).

pards• 4 years ago

This aligns with what Peter McBreen covered in "Software Craftsmanship: The New Imperative" [0] in 2001

[0] https://www.amazon.com/Software-Craftsmanship-Imperative-Pet...

HarHarVeryFunny2• 4 years ago

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?

hulahoof• 4 years ago

Strong opinions weakly held has worked well for me

MonkeyClub• 4 years ago

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.

AdityaSanthosh2• 4 years ago

I am curious. What is a strong opinion? How do you define it?

gwd3• 4 years ago

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.

ambicapter• 4 years ago

I find that such a buzzwordy phrase. Weakly holding a strong opinion seems oxymoronic.

kstenerud• 4 years ago

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.

koonsolo• 4 years ago

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.

monsieurbanana• 4 years ago

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.

mewpmewp23• 4 years ago

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.

kqr7• 4 years ago

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!)

underdeserver• 4 years ago

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.

NumberCruncher• 4 years ago

> The former knows enough about the state of the art in their area of the field

Considering something to be "state of the art" is highly subjective, therefore nothing else than an opinion.

agentultra2• 4 years ago

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.

mewpmewp23• 4 years ago

If you keep your opinions to yourself, there's no one to challenge them and so your opinions won't improve.

sibit• 4 years ago

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.

taco_emoji• 4 years ago

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.

rawgabbit• 4 years ago

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.

Ensorceled7• 4 years ago

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.

Rury• 4 years ago

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.

CamperBob2• 4 years ago

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.

29athrowaway2• 4 years ago

The industry is full of passive aggression, and fearful individuals that avoid strong engineers.

nevinera• 4 years ago

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.

code_biologist• 4 years ago

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.

Ensorceled7• 4 years ago

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.

jjav5• 4 years ago

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.

distortionfield• 4 years ago

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.

TheRealDunkirk3• 4 years ago

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.

JKCalhoun• 4 years ago

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.

yamtaddle• 4 years ago

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.

anonuser1234563• 4 years ago

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.

davedx• 4 years ago

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.

blindriver• 4 years ago

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.

29athrowaway2• 4 years ago

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.

djtango2• 4 years ago

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)

picometer• 4 years ago

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.

kqr7• 4 years ago

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.

xlii• 4 years ago

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.

alphazard• 4 years ago

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.

weatherlite3• 4 years ago

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.

seanmcdirmid2• 4 years ago

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.

esskay• 4 years ago

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.

Ensorceled7• 4 years ago

I worked with a guy who was close to a 10x developer on my previous team and we hired him at another gig. Yeah ... he was pretty burned out.

But the guy I mentioned initially ... he's still going strong 20 years later.

lelanthran2• 4 years ago

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.

bazoom42• 4 years ago

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.

whstl2• 4 years ago

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.

thorin• 4 years ago

I'm never going to be Linus Torvals or John Carmack, so does that make me a 0.001x programmer or them a 1000000x programmer or an ∞x programmer?

Ensorceled7• 4 years ago

Nah, it makes them a 100x. It's a bell curve and it's ok to be near the middle.

pookha• 4 years ago

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.

m3kw9• 4 years ago

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

Ensorceled7• 4 years ago

Worrying about being a 10x eng or not is like asking yourself if you are Einstein level smart.

I think this is the crux of it. I don't think theoretical physicists sit around insisting that Einstein wasn't a 10x physicist ...

908B64B1972• 4 years ago

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).

[0] https://blog.pragmaticengineer.com/software-engineering-sala...

[1] http://danluu.com/bimodal-compensation/

[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...

gofreddygo• 4 years ago

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.

collyw• 4 years ago

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

michaelcampbell• 4 years ago

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.

sophacles• 4 years ago

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.

Others I can think of off the top of my head:

vi[1], emacs, C, ethernet, smtp, ethernet, excel, rs-232[2], FTP[3]

There's probably plenty of others too.

[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

[3] another fun fact, FTP is older than IP.

bruce511• 4 years ago

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.

ilrwbwrkhv• 4 years ago

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.

qup• 4 years ago

Maybe you worked with .1x programmers.

c-smile2• 4 years ago

Well, yes and no.

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.

Jensson9• 4 years ago

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.

twosdai• 4 years ago

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.

danwee3• 4 years ago

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.

Who wants to be a 10x engineer?

sn41• 4 years ago

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...

kuharich• 4 years ago

Past comments: https://news.ycombinator.com/item?id=28797485

mianos• 4 years ago

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. "

https://quoteinvestigator.com/2012/04/28/shorter-letter/

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.

andai• 4 years ago

Re: #20: Always strive to build a smaller system.

There's a quote I love I'll repurpose here:

Forgive me this long program; I hadn't the time to make it short.

jhatemyjob2• 4 years ago

Skimmed the article, saw the author quoted Bjarne Stroustrup, closed the tab.

luigi23• 4 years ago

dare to elaborate on that?

jhatemyjob2• 4 years ago

He's a charlatan.

reledi• 4 years ago

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.

bcrosby95• 4 years ago

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.

comfydragon• 4 years ago

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.

danwee3• 4 years ago

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.

Cthulhu_2• 4 years ago

But knowing how different things suck is what makes you opinionated; not knowing or caring why something sucks is being indifferent.

wirthjason• 4 years ago

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.

ykovalenko• 4 years ago

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.

komali2• 4 years ago

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).

albertopv• 4 years ago

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...

rrgok11• 4 years ago

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.

travisgriggs• 4 years ago

I’m torn. I want to agree with you.

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.

rrgok11• 4 years ago

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.

bradwood3• 4 years ago

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?

rrgok11• 4 years ago

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?

computerdork4• 4 years ago

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.

CobrastanJorji• 4 years ago

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.

hbrn5• 4 years ago

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).

rrgok11• 4 years ago

Says who? Is there a law that forbids it?

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?

jasmer• 4 years ago

Love it!

Is there a way we can accelerate this learning?

basicallydan• 4 years ago

This is a very well written article, and thank you for the advice. Lots that resonates here.

onion2k• 4 years ago

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.

atoav• 4 years ago

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.

munchbunny• 4 years ago

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.

kqr7• 4 years ago

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".

koblas• 4 years ago

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.

haspok• 4 years ago

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.

nathias• 4 years ago

very good points, I agree with the sentiment, but the best code is not no code, it's negative code

danwee3• 4 years ago

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)

CM302• 4 years ago

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.

agumonkey3• 4 years ago

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.

noduerme• 4 years ago

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.

BerislavLopac• 4 years ago

This is called the second-system effect [0], and has been described by Fred Brooks in his book The Mythical Man-Month, published in 1975.

[0] https://en.wikipedia.org/wiki/Second-system_effect

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

MrGilbert• 4 years ago

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. :)

CM302• 4 years ago

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.

locallost• 4 years ago

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.

MEMORYC_RRUPTED• 4 years ago

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.

tluyben2• 4 years ago

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.

Octabrain• 4 years ago

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).

FieryTransition• 4 years ago

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.

watwut• 4 years ago

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.

mewpmewp23• 4 years ago

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.

throwbadubadu• 4 years ago

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.

marginalia_nu• 4 years ago

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.

now__what• 4 years ago

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.

manuelabeledo• 4 years ago

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.

bjornsing• 4 years ago

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.

danielovichdk• 4 years ago

I have read this post probably 30 times since it was posted.

Having been a software engineer for +20 years so much good is in this piece.

Thx!

idkwhoiam• 4 years ago

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.

RickJWagner• 4 years ago

Thoroughly enjoyable. My thanks to the author.

dgb232• 4 years ago

This section:

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.

scottLobster• 4 years ago

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.

dgb232• 4 years ago

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.

908B64B1972• 4 years ago

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?

javier_e06• 4 years ago

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.

vb-8448• 4 years ago

19. Interviews are almost worthless for telling how good of a team member someone will be

I definitely agree with this statement, but I would add `but at least allow you to discard who is definitely not good`.

slively• 4 years ago

Great write up! After 13 years I find myself reflect on exactly the same points.

Things I’ve learned in my years as a software engineer (2021)

Related Stories