171–180 of 217 posts
I praise 1x programmers, but for reasons that might go against the grain in HN. I'm from Spain so our working ethic is different from the Anglo-Saxon world. "Work to live, don't live to work" as the saying goes. My principles for a 1x programmer: * Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself. * 9-to-5 is a perfectly reasonable schedule. Fiercely protects…
Earlier quoted context omitted.
The principle behind being a 10x programmer is not working more, but working less and using tools that multiply you. The 10x dominates the tools ( and techniques and people and capital) that multiply her. If you have a car you can easily and consistently go 10x faster that walking pace. The same applies for your job. Working on a given company, with access to capital and people and tools can multiply you.
But to become a 10x programmer I think you need to put in more effort than if you "only" do your job.
Earlier quoted context omitted.
10x is a really bad term, it tries to quantify a difference without a baseline. The difference isn't in quantity, but imo rather in mentality. Relentlessly automating repeatable tasks can net 100x or 2x or 0.5x depending on context, but something that don't happen often enough.
10x implies there should be an opposite of a 10x, but it's unclear if that'd be a negative number or a 0.1x.
A negative number. A 0.1x programmer gets work done acceptably but is slow.
A negative programmer on the other hand creates more work for other people to fix, and you’d be better off not having them touch the code at all.
Earlier quoted context omitted.
The principle behind being a 10x programmer is not working more, but working less and using tools that multiply you. The 10x dominates the tools ( and techniques and people and capital) that multiply her. If you have a car you can easily and consistently go 10x faster that walking pace. The same applies for your job. Working on a given company, with access to capital and people and tools can multiply you.
What are the tools to multiply yourself in a software development setting?
I've never met a 10x engineer. (Does that make me the 10x engineer? I doubt it). Personally I believe that the myth of the 10x engineer comes from the very real and very visible fact that often times, one engineer will be 10x as productive as someone sitting in the next desk over. Why is this? There are numerous factors, and certainly innate skill and programming practice come into play. But I think that only gets yo…
Earlier quoted context omitted.
> ... , we don’t need novel software most of the time. We need better boring software. More general, less buggy, faster. Doesn't producing that kind of software involve novel , interesting ideas in the first place?
It’s only very slightly novel to apply solutions that we already know exist that were designed to solve a class of problems to a problem that nobody has done so for so far. Not being novel doesn’t mean it isn’t useful, though.
That leaves room for the software that actually does stuff to be boring.
These concepts are usually confused; even in the area of languages that supposedly you can't write bugs in, Haskell is too exciting in both directions (so it's too hard to use), but Ada/SPARK is too boring (so nobody wants to use it).
I've never met a 10x engineer. (Does that make me the 10x engineer? I doubt it). Personally I believe that the myth of the 10x engineer comes from the very real and very visible fact that often times, one engineer will be 10x as productive as someone sitting in the next desk over. Why is this? There are numerous factors, and certainly innate skill and programming practice come into play. But I think that only gets yo…
Two month later, A is done multiple simple tasks and in the middle of refactoring a tricky module to add much needed functionality. B is still working on their second simple task.
I would not be able to quantify difference between them, but it could easily be more than 10x.
(We later tried to see if B would do better at other projects -- a different programming language, a project that needed a small program from scratch instead of modifying our huge main codebase, etc... None of that did help.)
There is very little points talk about 20x or 1x without discussing the context.
What if, there is no reason that we only can have 1 20x programmer on the team? What if, we simply over-hired programmers and majority of the programmers shouldn't be hired as programmers and they made the 1x to be the norm and the software architecture has evolved to cater to these majority 1x programmer that we end up working with 1x teams, 1x management, 1x languages, 1x frameworks? And they made 20x unicorns? The mere acknowledge of 20x programmer exists is intriguing...
I am not saying one or the other, just what if.
In Peopleware, DeMarco and Lister write: Count on the best people outperforming the worst by about 10:1. Count on the best performer being about 2.5 times better than the median performer. Count on the half that are better-than-median performers outdoing the other half by more than 2:1. What nearly everyone who has read that remembers is the following: The best people outperform the average by 10x. Spot a difference?
this aligns with the hypothesis that some people have that a handful of people do most of the work (and the others are the "worst" performers"). What this misses, is that in any highly functioning teams everyone is important and in order for the "rockstar" to be the "rockstar" they need people to help keep the machines running and to support them. This is usually why a team that has a mix of both veterans and newbies…
The best programmers I worked with were not "rockstars", but "icebreakers" -- they would solve the hardest problems and leave the clear path for others. For example, they might solve a sporadic memory leak in a few hours, and thus save a less experienced team member at least a week of effort.
They were "10x" in the sense that any team they were on would get 10x better because everyone does more.
> Synthesis is essence of software engineering, whereas abstraction is the essence of computer science. Your job as a software developer will be to synthesise something new from composable pieces. What you create should be simple to understand and extend. Loved this.
It's a nice quote, but I really disagree with this section. Yes, software development is more concrete than computer science, but abstraction is so, so important. The author acknowledges the value of simplicity, but simple code is only produced by choosing the right abstractions. Getting even 1 key abstraction wrong can create enough "friction" to eventually kill a product if the tech debt isn't managed well. 99.5% o…