Hacker News new | past | comments | ask | show | jobs | submit login

I'm about 20 years into my programming career, and have been programming around 30 years total. I am very fast at lots of tasks now, but it has happened in a way that would be totally surprising to my younger self: I don't waste time doing stuff that doesn't matter.

I used to assume that the "10x engineer" was 10x faster at the programming/typing part, but it turns out it's more like identifying the 1/10th of the work that actually matters and just do that efficiently. It is also true that there's a lot of experience in both the identification of that 10%, and the efficient execution of it though.

Side note: I have also met a few flat out amazing, natural programmers. These people can also be 10x as productive, but it's in a pretty specific way that should probably just be considered an outlier. My feeling is that the main way for the rest of us to achieve that level of productivity is gain experience, do things simply and efficiently, and learning how to focus on the things that matter.

> These people can also be 10x as productive, but it's in a pretty specific way that should probably just be considered an outlier.

the 10x programmer is by definition an outlier

Most prevalent examples of failure to hone in on what matters?

This is a great question and I'm having real difficulty putting together a good list that's generally applicable, but not so general that's it's useless in practice. I'll give it a try (from the perspective of defining what matters):

1. There usually are just a few critical pieces to any project. You should try to start with those and get them locked down first. These can be critical because they are either technically unproven or just plain difficult. Once you know the hard stuff is handled then you can fill in the easy stuff from there on out. (You'll also feel less inclined to fancy-up the easy stuff, in my experience. That's another source of trouble).

2. Use quality tools, become an expert with them, and hold on to them as long as you can. What does quality mean? To me: reliability, stability, and efficiency of both my time and the machine's time. Knowing how to do something because you've done it before, seen the problems and worked through them, and come out the other side, is _huge_. Rarely rarely rarely, a new technology comes along that overwhelms the advantages that hard won experience provides, but it's super rare. This is a whole topic in itself, but in my 20 years the list of situations in which something new clearly brings enough benefits to switch are surprisingly rare. Off the top of my head (and just to make everyone mad in one easy sequence): moving to Java from C/C++, Hibernate ORM instead of endless hand crafted SQL, S3 instead of a probably-about-to-be-full attached volume, Heroku instead of running my own machine, Unity instead of my bad custom game engine, and most recently Flutter instead of native Android/iOS (although this one is still early days).

3. Be honest about what you're actually spending your time on, and optimize for that. A lot of the fancy programming languages of recent years have been spending huge amounts of time optimizing what, for me, weren't big usages of my time. I realize this is vague, but an example for me might be Scala. The stuff that they were improving looked fancy in examples, but it didn't make a material difference to me (as a Java programmer) in what I actually spend time on. It also came with a bunch of downsides, which is itself worth an entire post.

4. Don't be afraid of simple looking code. It might be slightly embarrassing to check in, but it's probably going to be clear how it works to you any other other person who needs to read it in the next few years. The urge to appear smart in the way your code looks can be deadly.

5. Be specific about the upsides you expect when examining a new technology. Are you looking to work faster, are you looking for performance in a specific category, etc. Failure to properly define your criteria leads to adopting things that are a bad fit for your situation (helllooooooo microservices) or at least provide minimal benefit in return for the _huge_ expense of throwing out experience in another technology.

I'm pretty sure there's lots more examples, but that's all I got at the moment. I will add more if I think of it. I guess this should all be a big blog post at some point as well, if it's something people find interesting.

This is a great list on what it means to correctly leverage engineering resources. (I would recommend doing a blog post).

Point 2 (and 5) is probably one of the biggest things I think about a lot these days. Most of my tech stacks are relatively tried and true, with the exceptions of Netlify and GCP. Where it's possible, I will generally try to put a $10-20 dollar SaaS product instead of code. That comes with counter-party risk, but I trust Pingdom more than I would my own notification servers.

When I wrote this article, I struggled with explaining how my thoughts of what a 10X engineer changed over the years. I recognized people would yell 10X != memorization, but the compound effect of working (and learning) without friction (in this case, human memory. in many other scenarios, technical debt) leads to exponential advantages.

Wonderful write up. If you end up writing a blog post please let me know.

That was fantastic. Thank you

I believe you and would be interested in your list of things that matter?

Not the OP, but my experience matches his and for me the following are particularly important:

- Getting the requirements right. This by far has the most impact on effectiveness

- Reducing friction. Simple things like proficiency with high quality tools, smooth and fast builds, clean logs, easy ways to generate and analyze core dumps, accumulate to produce an outsize effect on productivity.

- Uninterrupted, substantial blocks of focused time. It is staggering how easily chat, email and meetings can destroy productivity.

I was attempting to answer this elsewhere in the thread, but I totally forgot about uninterrupted time. This is a huge one, it really matters.

Quick tip: For people who work in a company where they don't necessarily have control over their own time: schedule the living out of your calendar. Book endless meetings with other programmers, then just sit there and do work. "Q2 Backend Architecture Review: 4 hrs" can just be a few people sitting in the meeting room programming. It's crazy the power of blocked out time on your calendar to a manager who otherwise sees an empty day.

This is a hilarious and amazing tip.

Another way I've tried to tackle this is on day 1 of a job - I've blocked out a huge chunk (4 hours) of my daily calendar of "Coding Time - No Meetings, No Slack, No Email" before anyone could tell me no.

If I could give you +4 million for the "blocks of focused time" comment, I would. This is hugely under-rated in my office.

Open plan, with 2nd line support talking to customers right next to developers.

Not really what he's talking about but one thing that has been great for me: no morning meetings.

My team has coordinated it so we spend mornings working independently on the most important things we need to get done. Only the afternoon is open for meetings. In those meetings we often identify things that we will each work on independently the next morning. This better planning leads to more focus and the reduction in distractions leads to more productivity.

Emergencies are exceptions, but it's amazing how rare those can be if everyone has a decent amount of time to handle their most important things every day. Also, many people are not well organized and this small amount of organization makes a massive difference.

I made an attempt to answer that question here: https://news.ycombinator.com/item?id=19533062

I don't think I quite captured everything, I might take another shot at this again sometime.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact