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.
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.
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).
* 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.
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?)
20ish sounds about right - in Switzerland, men loose a year due to military/civil service.
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.
Perhaps a compiler or something of similar complexity would be appropriate as a software "masterpiece". What else, I wonder?
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.
The dissertation about it is https://erlang.org/download/armstrong_thesis_2003.pdf
The movie https://youtu.be/xrIjfIjssLE
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.
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.
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.
"When you know that my poems are not poems, Then we can speak of poetry."
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
Ever managed to actually convert anyone back to sanity?
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.
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.
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 found that an elegant solution, at least in abstract, I've never actually see it in practical use.
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).
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.
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."
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.
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.
Considering something to be "state of the art" is highly subjective, therefore nothing else than an opinion.
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.
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 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.
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 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.
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.
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?
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.
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.
> 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.
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.
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.
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.
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.
This guy is out there on the tail end of the distribution.
"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.
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.
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 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.
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.
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.
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.
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).
 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.
Isn't it normal in basketball to have one guy dominating the points?
But the real differentiator is in (both programming and science) the depth and quality, not quantity.
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)
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.
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.
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.
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.
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.
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.
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.
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.
It's unenlightened to say that the 10x programmer is a myth without, as the author suggests, asking "why" a few mre times.
Maybe trivial but it does seem to be how it works.
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.
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.
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.
But the guy I mentioned initially ... he's still going strong 20 years later.
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.
Without defining the term more precisely, people can discuss this forever without getting anywhere.
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 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"  (Some use the term "dark matter devs" but I know it has another meaning ). 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).
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.
I think this is the crux of it. I don't think theoretical physicists sit around insisting that Einstein wasn't a 10x physicist ...
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.
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.
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.)
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.
I get what you mean now re: “important” though, I appreciate your reply!
For once, Agile is actually quite explicit about documentation. From the Agile Manifesto.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
There’s a balance.
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
Yes, api definitions are in code, but what our customers see is just as valuable.
If it’s not what they want, and they can’t support themselves with the doc we write we’ll be in a hellish back and forth with them.
Code is our love, and code can be GREAT at documenting itself.. but customers don’t ever want to view javadocs.
I am assuming an audience of devs and customers / users of an SDK - ie people that need to understand the code.
Support and sales (unless selling an SDK) should not see any code or code documentation at all.
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.)
OK I thought we were discussing code documentation. I think we see eye to eye on other types of docs.
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.
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.
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.
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.
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.
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.)
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.
I'm much more worried about building something interesting than building something with interesting technology.
People who actually switched from one to another (some forever some for at some time) are waaaay calmer in their opinions.
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.
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.
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.
First you focus on technique. Then you focus on the what.
> 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.
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.
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. :)
> 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.
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.
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.
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?
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.
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, emacs, C, ethernet, smtp, ethernet, excel, rs-232, FTP
There's probably plenty of others too.
 in the form of neovim and vim in particular, but also nvi, busybox vi, and probably others.
 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
 another fun fact, FTP is older than IP.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
My $0.02 on the matter.
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.
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.
And agreed, it is a lot of responsibility, but again, it's only when an engineer rises in their company.
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.
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.
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?
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.
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.
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.
It's not the industry that has wrong expectations from you, it's you who had wrong expectations about the industry.
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.
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.
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.
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.)
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.
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.
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.
There's a quote I love I'll repurpose here:
Forgive me this long program; I hadn't the time to make it short.
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...
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)
So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.
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.
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.
The cost with refactoring big legacy system is too high, to the impossible.
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
I definitely agree with this statement, but I would add `but at least allow you to discard who is definitely not good`.
Having been a software engineer for +20 years so much good is in this piece.
Is there a way we can accelerate this learning?
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).
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.
So I think this myth is propagated by those who aren't 10x engineers and just want to give up before getting there.
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?
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 ...
Козьма Прутков: (ru) Каждый человек необходимо приносит пользу, будучи употреблен на своем месте.
Kozma Prutkoff: Each person necessarily benefits by being used in his place.
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.
Different people - different areas.
Like in Sciter 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.
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.