* Software is a social service. Its for other humans.
Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.
My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.
His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".
He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.
A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.
Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.
Software is useless without users.
Edit: Ah, found it.
"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha
This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.
Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.
I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"
You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)
imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.
Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."
Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."
otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...
I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.
[1]https://cloudflare-ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...
[2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-ex...
Does it need to be social to be useful? That is a value system.
Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.
"software is communication, made by people, for people"
(which is more or less what you say :)
With all the consequences. Most people, on either side, don't get it. Ever.
Nothing between "click button" and "problem solved" is your user's problem, they're all yours.
- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)
- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled
- secretaries go faster using fucking paper and filling everything by hand
- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on
alas
I think I get what it means but how do I act on it?
Improvements in my "soft skills" have carried me further than any technical learning.
* If coders could write useful documentation (starting w/inline comments) they probably wouldn't be coders.That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?)
Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
The fact that this attitude is common scares me when I'm doing interviews.
Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it?
The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it.
So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
> People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates
I do not need heroes, I need reliable folks who do not burn themselves out.
Or to put it in a cliche... I need people who work to live rather then live to work.
Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
I just ask the individual contributors how much PTO they've taken in the past 12 months. It's more or less an open question, doesn't necessarily means I'm interested in taking too much PTO. You'd be surprised of how honest people are. I had interviewees even start venting about burnout. Someone from an e-commerce company (not Amazon) told me he's gonna take a month off as he took 0 vacation days for the past 1.5 years (!!!). He admitted he's probably going to get in trouble but he doesn't care anymore.
If you’re dealing with a reasonable person, you should be able to preface the question by explaining how having sufficient time off helps you do your best work and avoid burnout, and that you want to clarify expectations up front to make sure that you and the company are an ideal match.
It’s also of course a bit less risky to bring up this sort of thing a bit later in the interview process when you’ve built a bit of a rapport with the interviewer and ideally demonstrated your value somewhat.
They said "hey, we shutdown anyway during the holidays you can take it then, just start now"
and of course, did he get to take that time off? NO.
However, I prefer having some free time for myself than accumulate a large amount of money.
Edit: sorry if that sounded offending but I can't wrap my head around the fact that people in US have problems of this kind
It's plenty of time for my employer to extract value from me. If the org wants me to work more, they can make me be in meetings less.
The issue isn’t taking time off, it’s that the prospective employee’s head is up their proverbial ass. First interview is propspecting. If you were selling a product, if the customer is asking about the return policy before even selecting an option, it’s a similar signal.
When you’re in a subsequent interview talking about the benefit plan, salary, etc, that’s where that sort of question is appropriate - you’re finalizing the deal.
I've also worked on teams that, same as your friend, heavily implied that taking longer leave breaks were a no-go.
As with all things, it's a balance.
You CAN refuse once the contract arrives for signature, the interview is a lot also for the company to have argument to sell you to management as a worthy investment.
I admit I never take a guy talking about time off myself, because while I agree it's an important contractual part and something we must give as generously as we can, the fact he asked the first minute of our relationship means it's going to be painful for him and for us, because we're not a paradise company, things can be tough and high pressure (investment bank), people not nice on purpose and sometimes you have to do the right thing rather than the perfect thing, so compliant positive nearly sacrificial profiles will be happily surprised by what's still good while a dude asking "and holidays, 20 or 25 days" the first day will be very sad and burnt out by all the shit.
You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about".
You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
It's as if the notion of people being arbitrarily born more or less with a knack for something is evil.
Let me tell you the story of when I realized I was (at best), a "not-mediocre" dev:
1. I've been programming for fun even as a kid. That's what got me into it: If you count kid-programming as "programming", I've been programming for ~14-15 years.
2. There was a girl who used to work with me at $DAYJOB, who is fairly well-known on The Orange Website, and has written some "thought leader" papers in certain niches. A real einstein.
"A couple of years -- and a few of those were writing another language. This is my first real job writing $LANGUAGE_WELL_KNOWN_FOR."
This is called "innate ability". Humans aren't created equal, nobody said they had to be, and it's not a crime to acknowledge it. Folks ought to get over it IMO, it's not a big deal.
I will never understand CS and programming-language theory concepts at that caliber or that intuitively, but who cares?
I'm also short as fuck so I doubt I'll be playing in the NBA anytime soon either. Life goes on.
I think the idea of 10x programmers gets so much pushback because it's often bundled with this kind of toxic hero worship. There's a difference between acknowledging the impressive ability of outliers, and idolizing heroic one-man efforts as the pinnacle of what we should all aspire to as software developers.
Incidentally, Carmack was not the only programmer on early id Software games, and Doom was far from the first 3d first-person game made. Arguably, it wasn't even that ambitious compared to, say, Ultima Underworld, but the programmers working on that get much less immediate recognition.
As a matter of fact, these discussions often remind me of that famous IGN quote of Warren Spector. Except we really should know better on HN.
This is discussed in the book Make It Stick on learning science, in chapter 7 they discuss how your own views on whether skill is innate vs the result of practice affects your own ability to learn and grow.
In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others. I think this is the notion people oppose.
Another analogy is the 10x classical composer. A person who produces music that is 10 times better music. But this is much more about creative/artistic capacity than about producing. Nobody oppose this.
I that your examples incarnate the same idea: It is not about producing code faster. It is about having better ideas.
Most projects out there will not benefit from such a person. If you don't understand this, then in my book it makes you a poor employee. I mean, it's great if this 10x guy can solve some challenging problems that most people cannot, but if that 10x guy cannot show how it helps the business, I hope he's not in my team.
Most businesses are complex and messy. Connecting your code to business value is not easy.
Looking at some of the comments here, people are going out of their way to both defend the existence of 10x programmers, while simultaneously working very hard at not putting any kind of metric on their ability (e.g. "no, it doesn't mean they can produce 10x code or replace 10 people or ... it means <something very hard to measure>"). If you're going to insist on some quality that is hard to quantify, then stop using numbers to describe them. They are geniuses, but not 10x.
In my experience:
1. You cannot replace 10 average programmers with a 10x programmer and hope to achieve the same output. Output, by the way, is not defined by code, but by activities that help the business move forward.
2. While there are some good claimed 10x programmers who work well with others, most of the ones I've encountered do not. In my last job, we had a team of several truly brilliant folks. They could dive deep to the assembly level or work at the system level (scripting, etc). Any bottleneck that arose - they would dig deep and figure it out.
It was the least productive team I've been in. They argued amongst themselves on the pettiest of things that had no impact on the business. When asked why I was leaving the team, I literally told them that I want to be in a team that writes SW. That team's productivity was so low I couldn't reasonably claim they wrote SW. It's not that they didn't write code, but that most of it would not see the light of day because of constant bickering.
Even more impressive, much of the success of later titles came from his picking the likes of Abrash to help make things fast. Notably, the WTF comment in the "fast square root" trick was from Carmack about a contractor's code that was speeding things up.
Getting even more meta on it, they had amazing dev tools at their disposal that many other programmers just couldn't afford. Look at the recreations folks do nowadays using pico8 and friends. Some folks get some really amazing tricks running in that field.
None of which is to say Carmack is a bad dev. Quite the contrary, he is quite good. But don't discount the role of everything else to the early success that Doom and friends had. In particular, the artistic execution and vision of everyone else was probably worth more than you'd consider.
I think it's a mistake to conceive of the difference as one between the tortoise and the hare, where the tortoise gets there, eventually. There are bits of this code that the tortoise just wouldn't ever end up producing if you gave them all the time in the world.
https://norvig.com/spell-correct.html
How many developers do you know that would bang out a spelling corrector on a single plane flight, in half a page of code?
It's a question of knowing the algorithms of tools that make things possible that other developers might not even consider, and how to express those ideas cleanly and concisely, evaluate your solution, and iterate and improve quickly.
And then consider the quality of his documentation and considerations for improvement and future work.
I remember someone laughing at the idea of 10x programmers. I asked him where he hired from and what's the compensation like. Turns out two high performers I had recently hired were from the same college he was trying to hire from. Of course, he had no chances of attracting anyone since my offer was ~3x what he was offering!
Because we're programmers, we chose an empirical measurement ("10x") as our term for high skill. This terminology is confusing and stupid, but now we're stuck with it
Exactly. There are many modes of that, and you named a few examples. Another example, company has 2 systems maintained by 10 people each. Someone comes in and figures out how to generalize one of the systems to both cases, so they free up 10 of those programmers to go do something else.
Or - 10 people are beating their head on a problem for months, someone comes along and says "it might be OK if we don't solve that problem, let's move on"
Or - someone figures out that a system/module doesn't need to be written because an out-of-the-box solution exists.
Like, I am not a 10X programmer in the sense that I can write 10X the code of the next guy. But have I prevented 10-people's-worth of wasted effort in my career? Yeah...
>You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to.
Yes Doom was a great game, and well programmed, but it didn't really move the state of the art forward massively, as I would argue that hundreds of programmers had already written and published 3d games by that point.
Just to be proud and gain that dopamine?
Continuing with this analogy and using Kuhn's concepts, maybe it's better to bracket out breakthroughs (paradigm shifts) when talking about everyday productivity (normal science).
We all know people who code faster than the rest of the team but they always cut corners. Part of the reason that everyone else is slower is because they're trying to work around the under-tested tightly coupled mess left behind by the 10x guy.
Then there's the 10x complexity discussed in the parent comment. Plenty of people will take years to solve a problem, if at all, that someone else would manage in a month. However this may be reversed for a different problem since it depends on experience and predisposition, so it makes no sense to talk about a '10x engineer' in this regard.
I share the conclusion with the OP that it's a vague and ultimately useless distinction.
If your development needs are mundane crud stuff, you don't need a "10x programmer". If you're doing tricky stuff, on the other hand, you absolutely do.
I looked at one of the problems of the final round, looked at the solution, read it for hours, and I couldn't implement it correctly.
Then, there are these top 3 who came up with their own solution and wrote correct code within 20 minutes.
For comparison, I can consistently be in the top 1000 of Google codejam. So, I consider myself a fairly good coder.
I experienced this with topcoder as well. There are some people who are way too smart.
10x programmers and engineers are very much real. It is just rare.
but the reflex for humans is to fear and be angry (understandably, but a bad reflex)
0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.
I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers, but it seems so totally detached from reality. I'm not sure the "benefit" of propagandizing against talented assholes is worth the cost of demotivating people who might be inspired that they could become a 10x engineer.
Yes but I think the underlying issue is that some people really Really don't like to acknowledge (or are unaware) there's a small set of elite programmers that can do things average coders can't. But any label we use to describe them (i.e. "10x", "rockstar", "ninja", etc) will be psychologically distasteful. I previously commented about that effect:
- https://news.ycombinator.com/item?id=13753178
- https://news.ycombinator.com/item?id=24753594
To see that hidden psychology driving the narrative... look at how the author constructed his comparison with extra qualifiers of "competent" & "similarly experienced" : ">The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly."
In other words, if we artificially construct the comparison by a priori assuming both programmers are equal, then the 10x difference is a myth. Well yes, that's tautology. If you invent a sentence to "prove" a point, you can set any conditions in the artificial universe in your favor that seems to support it.
However in the real world, the stack of resumes will have a candidates with wildly different skill levels. Some struggle with Fizz Buzz. Some can write a 3d game from scratch. But it's impossible to create a label to describe that wide gap which also doesn't invite bikeshedding on that label.
EDIT reply to: >"Why can't we call them master programmers?"
Because we'd still have endless bikeshedding of the label "master" as in "Master programmers are a myth..."
The first one was not a bad person by any means, but had no social skills, no ability to communicate and often just forged ahead building great stuff on his own. Entire areas of the software were entirely conceived and created by him, and it was difficult to even grasp what he was doing while pair programming with him. In a day he would write more tests and get more coverage than the rest of us would create in a week.
The second one had come from a FAANG-ish place where he was extremely successful, but didn't want the money or stress. He was extremely kind, considerate and great at communicating. Pair programming with him was a joy and he helped everyone else on the team grow. I'm confident he could have created entire regions of the software on his own, but he knew that wasn't the right thing to do. He would often ask questions until someone else on the team could solve a problem, even though I'm sure he knew how to solve it easily himself.
Both qualitatively and quantitatively, their output is at least 10x of a typical developer at a typical company, not even counting everything these people do besides writing code. Many more are not famous but are in the same league of impact/productivity - I'm genuinely puzzled how someone can say such people do not exist.
* Documentation
* The debugger / print()
Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.
> The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
Over such short time scales, maybe, but the idea that someone could contribute in 1 year what another programmer wouldn't accomplish in 10 years is highly plausible, to me.
Someone who can sit down and start coding in an ambiguous environment, period, can easily make 10x more value themselves, and allow others to go from .1x to 1-5x merely by being able to pick somewhere to start and just doing it, which allows everyone else to break their own ‘freeze’ and start engaging as now there is something concrete that breaks the locked up state they were in.
I’ve done it a few times, and seen others do it to. It’s magic going from ‘everyone rehashing things on a whiteboard for the 10th time’ to ‘everyone working on the next iteration’
Even worse than super-subjective, it seems like people don't agree on the definition of "10x programmer".
Is that 10x value (code * code quality) produced per unit of work-time? Per brain cycle? Are you controlling for programmer experience, or domain knowledge, as [1] pointed out? Do you actually mean 10x, or is that a stand-in for "significantly more productive" with an unknown value? Do you include collaborative skills and working with a team, or even entirely base your definition off of that?
I'm both curious as to the exact definition you have in mind, and also trying to point out the more general issue so that others arguing past each other can realize that they have two different ideas in mind.
IMO that attitude never makes sense - it can make sense to avoid certain mistakes at all costs (self-driving car), but it never makes sense to try to avoid blame for them (company refuses to admit their car isn't good enough).
This is a problem of culture, not individuals.
Does the culture at a company openly admit mistakes, try to learn from them, and put systemic fixes in place to address them, or do they punish people for mistakes?
If the latter, you end up with nobody admitting to mistakes and a terrible culture, it's not about the people, it's about the situation you have put them in and the incentives given to them.
I'm living this at the moment and it's driving me crazy.
I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?
I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.
- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.
- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.
Just this year I was working with another team that wanted to move to an architecture that I thought was overengineered for their specific problems. They shared with me an article about some company that was using it. I explained my experiences with such a pattern and where the pitfalls were, hoping their lead dev would think about it or discuss the pros and cons. Well, it was met with silence. They went ahead with their plan anyway.
Too many times that’s happened in the work world, so at least now I don’t invest a lot of effort into changing minds. Best advice
I’ve learned these last few years is don’t tie yourself to your work. If you’re opinionated about how to do things because you love designing software, that’s great, but you’re setting yourself up to be disappointed by how things really get done.
There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.
After couple of years people realize that just having opinion and being vocal about it does not make one a Senior/Manager/Leader. There is much more to it and one learns about it on the job.
Senior dev: This won't work but it's no use explaning why since they've made up their minds (as have I).
I feel that if I present what I think we should do, and why I think it's the best alternative, I shouldn't have to get into a shouting match or even a debate. I don't take it personally if people disagree with me.
If I've got the best ideas and my managers are ignoring them for the loudest ideas, that's on them, not me.
As always the wise approach is probably somewhere in the middle, in this case choosing your battles. You don't have to voice every opinion, but you shouldn't be silent if you have a strong and well-formed opinion about something important.
I’ve worked with too many people who think that their opinions are their identity and defended them as such. A difference of opinions shouldn’t become an excuse to go to war with your coworkers or argue endlessly instead of getting things done.
One of my worst work experiences was with a team of developers who were old friends from a college debate team. We could never have any productive discussions because they entered every conversation intent on winning instead of having an honest, productive conversation.
The best engineers I’ve worked with have had strong opinions but have also been happy and willing to go a different way if that’s what the team decides as a whole.
Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones.
For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions.
My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.
That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.
That's what interviews are for.
Or maybe he just thought she looked hot, and was afraid of appearing to be ogling her too much. Sometimes people fuck up by trying too hard not to fuck up.
Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs.
I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
I went spelunking a bit in my own code, cursing the jerk who built some of it, praising the genius who put in other parts, remembering cutting certain corners to get home for dinner on time, etc.
Having to support anything 10-15-20 years down the line gives you a different perspective on maintenance and simplicity that I don't think you can quite ever really comprehend beforehand.
1) "No, my 37 day interview process is good, actually."
2) "Rails sucks"
3) "Making a thing people would want to use is a bad idea."
4) (two long threads) "The 10x programmer exists, I saw him once at a con."
5) "No one cares what anyone else thinks."
HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
+1. Most (including me) internalise, if at all, this lesson the hard way through trial and error.
I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data.
I expected Domain Driven Design (DDD) would address this but it doesn't.
(I think then that was more or less true, but the numbers in the industry as a whole have gotten a lot better in the past 30 years. And I've gotten better jobs.)
Database design - normal form, relations, etc - was a major part of my education. Surely that's not unusual?
> “How can you not know what BGP is?”
I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge.
Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!"
Anyhow, to put it bluntly, don't be a dick about it.
I hate when people do it to me, so no idea why I was doing it right back.
>> Nobody asks “why” enough
This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person.
>> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on.
It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
They’re so accustomed to those things being signs of assholes, or reasons to feel inadequate, that they resist looking at what’s being delivered.
The OP’s point about bracing for a long battle means that truly persuading others is not just about making the amazing thing. It’s about having the humility to weather their resistance and care harder than they do about the merits of the way. And patiently, tenaciously demonstrating the value instead of doing anything that seems like boasting about it. Then they’ll stop ignoring you, and you’ll both win.
To add to what another poster said, it's not jealousy.
Big companies move slow because generally, to get big, they had to be successful (to some extent) and changing too much all at once is a risk that the bureaucracy isn't always comfortable with.
One of my old managers (I work in "enterprise") used to say things like "the efficiencies that this solution will bring the company..." which was just a euphemism for more folks getting laid-off (happened all the time, and glassdoor was full of warnings about this) or more jobs being shipped to our offshore units or even down-sizing in our offshore units.
I think it's reasonable, at least in the US, where healthcare & retirement & welfare is so tightly coupled with employment, for folks in big companies to be wary of innovation. They might want their job to be easier, sure, but too easy and they could be out of a job (for example, if the workload that previously took 5 people can now be managed by 2 or 3).
We're building software for people.
Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
Being good at what your company does is often not that useful anywhere else and usually you get non-compete so you cannot really use it.
If someone is a dev it is better to switch jobs and sharpen your "software stack" skills than waste time on learning whatever business needs. Of course there is some level that one has to understand the business they make code for - but don't overdo it.
If you’ve been at the same place 5-10 years you have seen only a few rodeos, as it were. Their speculations on how things will play out are based largely on hope, not experience.
Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably.
I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools.
2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again.
3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
Every time I rewrite my CV I always think, finally it's picture perfect. Next time I revisit it, because I'm looking for another job, I always think, who the F wrote this piece of crap.
I'm either slowly making progress or I'm running in circles.
I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
Just curious, how do you know that (a) you failed in HR (b) that it was this question and (c) for this reason?
I ask because it's unlikely that this was literally the feedback given you. Also, "I work too hard" does sound a bit canned.
>> The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems.
I do think this is more "in your head" that real. Nobody shows up to an interview wanting the other person to fail, but "how they solve whiteboard problems" isn't the goal either. It's more about - how does the person, think, collaborate, make tradeoffs and drives to an outcome - the goal being specifically to translate that outside the whiteboard space.
Ironically it was his honesty in that interview that won me over. For a junior role I'd rather than a rough diamond who I can shape than someone who already thinks they're perfect. And he turned out to be an incredibly good hire too.
Despite being a hiring manager for many years, I still dread getting asked this question myself. It is easily my least favourite interview question. Even the "Explain an occasion when you disagreed with your manager" question is much more favourable than being asking "what is your worst quality".
I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.
Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it.
You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too.
That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are you doing working for someone else anyway? Are they paying you 1M a year?
These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week.
* "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen.
* "Oh, but they didn't consider user requirements." They did.
* "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates.
And so on.
So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!
A week after the interview I was told that they don't want to continue with me because I didn't ask enough questions and that my solution wouldn't work if millions of people would use the system at the same time. I think I avoided a bullet
People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
Ain’t that the truth. I’ve come up against this my entire career.
This is so important. I think a lot of the advice given out there comes with the bias of having been successful doing it. There are countless others who have tried to scale the same ladder, doing the same things even, and still did not achieve the same success.
Very true... just yesterday someone posted about the Pony language main user switching to Rust:
https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust
Despite Pony being an impressive programming language, technically, with a lot of promise, pretty much only one company ever used it and now that it's moved on, Pony is pretty much in the camp "no one uses it".
And much of it is serendipity. A few tiny things could've happened differently, and now everyone would be talking about Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone remembers that??) VS Kotlin.
21. Do not mistake hype and popularity for quality.
22. The best code is no code, but configuration is worse than code. Maintaining 1000 lines of YAML is worse than 9000 lines of code.
23. The best code is no code, but replacing a script with a zoo of tools and libraries is often worse.
> This article will examine the unnamed and potentially devastating constraining effect of software on human autonomy. I call this concept residual causality, where software design decisions made long ago in different circumstances for different reasons constrain human action in an unknown future. The less aware the designers of software systems are of complexity in social systems, the more likely they are to introduce residual causality."
Only thing that I would add to the context:
If someone is a junior developer and has position where he has to "just write code" don't worry much about that advice. Yes you should understand what this advice is and look for ways to grow into that mindset but as junior dev such person still has privilege to fully focus on coding stuff as quickly as possible to learn have their movements worked out.
Then as such junior gets to 2 or more years of experience this advice should sink in and such person should start working as those points guide. After 2 years of being code monkey and having the feel for the code one can start looking at bigger picture.
1. This industry is very faddish, and many fads are designed to make money for the people driving them or lock you into someone’s ecosystem. Avoiding those is a superpower. A ton of today’s cloud native trends fit into this category. They are gateways to a paradigm where you buy a lot of things as a service at a massive markup that are relatively easy to do locally or obtain at much lower rates.
2. Simplicity is harder than complexity. Managing complexity is merely clever while eliminating it is intelligent. Eliminating it without sacrificing coverage of the problem domain is genius. There is some very interesting academic literature on the idea that intelligence is or at least heavily involves data compression (and that this is what "learning" is), so this has some basis beyond the field.
3. Unfortunately re: #2 more complex less elegant solutions often win. Many argue that this is because they capture more of the problem domain, but I often disagree. I think it's a mixture of sophomore developers being impressed by complexity (having not yet learned #2) and the fact that complexity creates industries where money can be made on adjacent software, services, and consulting. As a result of the latter complex clunky solutions can be better at building an ecosystem full of self-interested evangelists. Recent example: Kubernetes vs. the Hashicorp stack.
4. If you make something work, you are only maybe a quarter of the way to making it a product. UI/UX is the rest of the journey. UI/UX tends to not be fun, so people have to be paid to do it. This is why open source and open systems almost always fail to achieve wide adoption beyond developers and IT people. They have no economic model, so they can't hire people to make the product usable for people other than nerds.
5. Infosec people are usually afraid of the wrong things. Most breaches involve social engineering or a passive mode of entry. Infosec people like to obsess about things that are sexy like cryptography but will happily type "npm install" as root on production and pay far too little attention to security against social engineering vectors.
6. There are 10X (ish) developers just like there are 10X athletes, 10X mathematicians, 10X writers, 10X salespeople, 10X musicians, and so on. The reason many people don't believe in 10X developers is that it's so hard to objectively measure developer productivity, especially at scale.
> The best code is no code, or code you don’t have to maintain
I always say "The best code I write, is the code I don't write."
"Don't assume anything".
So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.
I don't have 20 years of experience yet. But my PoV is as follows: assume as much as you can and ensure that if those assumptions are broken, you have fail-fast-and-log triggers (when it's possible). So when that trigger hits, you'll understand what assumption is broken. For example in Java I'll write Objects.requireNonNull(x, "x") and move on. If that assumption is broken, I'll have stack trace in my logs and I'll write additional logic. It won't take much time. But if that assumption will not be broken, I just saved few hours of time and few dozens of LoC from future maintenance.
Some people hate NullPointerExceptions and want to get rid of them. I love them. They're incredibly useful for me.
This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.
I've been in the game for almost 30 years. I often feel like I know less than I thought I did 25 years ago, and that I know less as time goes by. I'd also have this as my #1 on the list because it just feels so surprising. I think most of us start out in our 20s thinking that in 30 years we'll have mastered the field, but it definitely doesn't feel like that, not even close.
That being said where you lay on the scale depends on context.
In my previous project I was a [-0.25;0.25], so I quit, because I was miserable and so were my teammates who had to work with me.
Now I'm doing great and even helping others be more productive.
It's harder than you think: The name of the game is to avoid fooling yourself and you're the easiest person to fool (that's from Feynman). If the problem seems hard it probably is harder than you think. Be ruthless and don't settle for unsatisfactory, hand-waving solutions to these problems. Most people can't detect deadlocks or temporal properties of concurrent programs in their heads.
I've been pondering the wisdom of having engineers do interviews at all. Interviewing, and getting someone to reveal their hand to you, is a massively specific skill, one that few get good at, let alone software engineers. Why is it that we think a 2 hour course on ethics and STAR can make someone capable of telling the difference between a con artist and a genius?
I do wonder if having a professional hiring team to dig into who the person is, and then just trial them for competence would be a superior strategy?
- Simplicity is everything. Complexity is fun but business is not about fun. It’s about solving problems. It’s about having other people be able to read your code and quickly understand it. Or having a system that can be debugged without a PhD in the specific tool you’re using.
- Everything is a tradeoff. If something feels too good to be true it probably is. If it’s easy up front, it’s probably hard in other ways. If you want to make something faster you’ll probably need to make it more complicated.
Technology in CS ends up instead being taught to be magical progress fuel that brings us towards the inevitable future rather than tools built by people with access to capital in order to achieve specific ends
Incredibly high performers exist, but are rare.
For example, the following quote is from a talk given by Gabe Newell.
(Unfortunately, I do not have the URL to the source video for this quote.)
“At IBM in the 1980s, typical productivity would be 1,000 debugged, shipped lines of code per year. That was the metric that they used for their median employee. Where as, when we were shipping Half Life 1, one employee, Yahn Bernier, was shipping 4,000 lines of code per day.”
There are startup CEO's who won't settle for anything less than a "10x programmer" and waste everyone's time trying to find one.
There are narcissistic coders who think they're "10x" and therefore can act like spoiled children to everyone around them.
If I hear "10x programmer" in anything other than "...is a myth" then it's a sign that whoever is speaking is probably someone I don't want to work with.
But there is no "mastery" -- lifelong effort is required from all of us, especially to avoid falling into fashionable bad habits of the moment propagated so vigorously by our social media.
> ... good of a team member ...
"The word 'of' often intrudes where it does not belong, as in 'not that big of a deal'"
- Garner's Modern English Usage, 4th edition, page 647.
In my 20 years of experience quality of software engineer comes down to personality, the ability to make decisions based upon evidence more than intuition and the ability to make decisions in the face of insufficient evidence. There is a certain vision of systems that cannot be taught as many people are incapable of accepting concepts of economic abstractions outside what they can put their hands on.
My problem is I’ve heard of it, probably even know a bit about it but never used or worked with it. Meanwhile it seems like everyone around me is both an insane domain expert in their own thing while also a pretty damn good generalist having worked across everything.
> 17. Keep your processes as lean as possible
> 20. Always strive to build a smaller system
He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines.
Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity.
> Project size is easily the most significant determinant of effort, cost and schedule
https://blog.codinghorror.com/diseconomies-of-scale-and-line...
This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.
Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity.
This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar.
I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.
Exactly my words two weeks ago: https://news.ycombinator.com/item?id=28640661
We as an industry really should put a lot of effort into helping 0.1x coders improve their skills to 1x level.
> 1. I still don’t know very much
Same here, Im still realising how much I dont know.
> The 10x programmer is a silly myth.
Yes it is. It's a stupid harmful myth. Everyone on HN and Reddit think they are the "10xers", and its used as an excuse to be rude and insufferable.
Some time ago, I decided I'd be happy being a 1x programmer[1]
> Don’t mistake humility for ignorance
Very true. Some of the best engineers I worked with, those who would never get job at these 10x companies, were quiet and reserved. But when you actually talked to them, you realised it was humility and a willingness to learn.
> Interviews are almost worthless for telling how good of a team member someone will be
Yes, interviews are just a form of hazing. The survivors are those who can stand the hazing, not the best programmers
1. https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
To survive in this field, one has to accept the fact that everything he/she's worked so hard to learn and master is gonna be replaced by something new in a few years. Don't fight it. Embrace it.
If I am giving you advice, you should know my context. It'll help you determine if my advice is useful in yours.
Bravo!
I've always found this to be very true personally. Unfortunately fear often directly opposes it, i.e concepts like "what if that guy gets hit by a bus" which are valid but sometimes taken too far to the point of attempting to make everyone easily "replaceable"... i've a saying to warn of this that has helped me alleviate such fears in others so far:
If you make your entire developer team replaceable, they will create code and products that are equally replaceable and hold no value. People are the company, they need to be valued as such.
Showcase your work as much as possible and refine your ability to do so over time - Not only does regular showcasing of things you've built improve your reputation within a company but also allows you to disconnect from the implementation and focus on how something will be used. You'll often find bugs, shortcomings, or opportunities for improvement that you may otherwise have overlooked. Look for opportunities to showcase wherever possible and advocate for opportunities if they don't exist already.
N× programmers for N>1 are mostly not N× cowboy solo code slingers, lots of gains are in enabling other members of the team.
The idea that programmer contributions to output are all in solo code slinging is a close cousin of the myth “programmer contributions can meaningfully be measured in lines of code”.
Yes, especially umm... everywhere in life. `s/sometimes/most of the time/`
> Sharks, not dinosaurs
Gonna remember that one, thanks.
Junior developers often get lost while trying to design a super complex system, which satisfies all the requirements, while it doesn't really need to be that complex.
I'd like to add that one should catch oneself when falling into the "Perfect is the enemy of good" trap. As engineers, we would like things to be perfect, but sometimes at the peril of late delivery, little feedback, and development of features not required.
I found that another thing which separates a junior from a senior is tendency to give up and cut corners. Stuck a wall making that integration test work? get back to it after the current task, don't settle on manual testing.
But maybe that's a trait of bad developers, rather than junior ones.
I think the 10x programmer myth was never about productivity. The idea is more about creativity. I.e. one creative programmer can create a product that would have never existed otherwise.
In a specified amount of time, N, what is the conditional probability that the engineer, e, can design and code a solution which is (relatively) error free?
This shifts into [0, 1] and is really asking the more important question.
"the best way to deal with complexity is to remove it"
I disagree here. A 10x programmer (or whatever other metric you want to use) brings a high level vision and uses that to turn around things faster like building Dynamics UIs, automation, or other tools.
That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document
Just remember, at one point every gallon of biodiesel in the US had its own serial number.
Nothing worries me more than the opinioned. Open your mind. You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.
> Every system eventually sucks, get over it
I'm a fresh recent grad developer, and this is good to know to calm me down from over architecting. I'll do my damnedest, but it's to know it's not awful if things get a bit messy eventually.
In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.
I feel the opposite. I'd rather have no opinions rather than have strong opinions that prevent me form seeing new possibilities. Infact, I work hard on keeping my opinions under control.
Yeah no kidding. I learned how to write code in notepad but now it's like what happened to me :(
* You don't know what the hard part was until the software is in production.
* If you know the right way to do it, do it the right way.
One of the things that I have learnt is how important effective communication is for software developers. It can make or break the products.
Don't assume anything.
If it is not the worst case, be happy, it saves you work. If it is the worst case, be happy, you expected it.
1. This is great advice
2. The overall spirit applies to any and all roles across any company.
3. YMMV
5. Software is a means to an end
these x1000!
Thanks for a very succint, distilled list.
* companies and/or owners don't care about you. take everything you can get and don't be shy about it. don't listen to them when they continually tell you that you're "highly paid"
I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
> 1. I still don’t know very much
Yep.
> 2. The hardest part of software is building the right thing
That's definitely hard but I'd say it's the people that are the hardest part.
> 3. The best software engineers think like designers
I'm not sure I entirely agree. It's also in total conflict with the growth economy the employs many of us; properly designing stuff takes time. No matter what, I always end up in a situation where "they want this as soon as possible". Being able to take the time to actually design something seems more like the exception than the norm. The only way around it is experience so that something resembling good design can occur by knee-jerk.
> 4. The best code is no code, or code you don’t have to maintain
> 5. Software is a means to an end
> 6. Sometimes you have to stop sharpening the saw, and just start cutting shit
Yes.
> 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Honestly, I don't that any of us have a good grasp of the universe of possibilities. A "good" system is highly subjective. Bad code is at least somewhat measurable if it doesn't work, isn't efficient, or takes a long time for engineers to understand.
There may be no such thing as good code. There's working code and there's code that fails to do its job.
> 8. Every system eventually sucks, get over it
I'd put an asterisk in front of "every". Many "good" systems turn out to suck not only because people ruin them but because engineers learn, grown, and change. While I tend to hate codebases more over time, there are some that I come back to years later and am still impressed by.
> 9. Nobody asks “why” enough
Yes. This has to be part of company culture, however. Many get defensive when subordinates question even the simplest of things, no matter how much they encourage that you "ask questions".
> 10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
Maybe, but I've met more 10x developers than I have 0.1x. And I've met exactly one 10x developer.
There was one guy who got canned at the first company that I worked for, and my bosses justified it because they thought he "wasn't doing anything". In actuality, he was directed poorly. Some people can just ignore bullshit management but others need seniors who can provide direction and some level of mentorship. That doesn't mean they are 0.1x developers. It may mean that team leaders haven't managed to find that developer's particular strength.
The closest I've found to 0.1x developers were some dudebros I met during my education, but every one of them flunked out.
> 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
I've always had opinions so I'm not sure I relate to this as a senior engineer. I have more opinions, and sometimes more nuanced ones, but in many ways I feel similar to how I did as a junior engineer. I'm frequently astounded by how much more I need to learn.
I guess the major difference I see is in the kind of opinions. Many juniors have opinions, but they are largely additive. Senior engineers who have been in the battle field long enough have opinions but they're more subtractive, or saying "you know, we don't need to add more steps to our toolchain, and maybe we don't need another framework".
> 12. People don’t really want innovation
Innovation rocks the boat for businesses beyond a certain "escape velocity" and what many consider "innovative" is actually confusing since innovation by definition is non-standard.
> 13. Your data is the most important part of your system
> 14. Look for technological sharks
> 15. Don’t mistake humility for ignorance
Yes.
> 16. Software engineers should write regularly
Meh.
> 17. Keep your processes as lean as possible
If I had things my way, I'd get rid of "standups" and "retros", uninstall unadulterated bullshit like Pivotal Tracker in favor of something much simpler like Trello or even a Google spreadsheet, eliminate estimations, and only have meetings that are goal oriented.
> 18. Software engineers, like all humans, need to feel ownership
> 19. Interviews are almost worthless for telling how good of a team member someone will be
> 20. Always strive to build a smaller system
Yes.
The more you learn the more you realise you were wrong.
Having an opinion has often come to mean one is a fan boy of something and will have it no other way.
I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all customer data together"
Bad opinions formed can be dangerous and counter productive.
Though I do agree that an opinion based on having a well thought out plan and experience is a sign of maturity.
K.I.S.S. is a great principle, but inexperienced devs really have no way to understand what is small/simple and what isn't.
If you find yourself doing 3 unrelated things before you can finally get to the one thing you were meant to be doing, it's probably already too complicated. If you build it really simple, it can look under-designed, or inefficient, or out of date. But if you find yourself thinking, "this would be better if it were a little bit more complicated", you might have just hit the sweet spot.