Effort and programming
I'm in my early-mid twenties now and a lot of my friends are working super hard at their careers, research, relationships, fitness and more.
Effort of some kind is certainly necessary to being successful in these endeavours. But there is a clear difference in outcomes.
I find this curious. Maybe it is a law of nature and we've been conditioned to believe that you can be successful if you just work hard enough, but I think that that is incomplete.
Programming is an interesting case. It feels subjectively to me that the best programmers I interact with are an order of magnitude better than the average.
My working understanding is that there a few things:
Comparative advantage
Don't believe in comparative advantage.
There's a bit of a hyper-specialisation going on in programming. We have terms like "Machine Learning Engineer", "Front End Engineer", "Data Scientist", "Product Manager".
We all (should) know that these are made up labels and really just represent clusters of skills. Unfortunately, humans are extremely tribal and take written labels seriously, especially if they are looking to "career-climb".
The best way to lead people is to do so by sheer force of aptitude. The other way is to hyper-specialise all of your colleagues to the point where you need a coordinating mechanism (the managerial class). I like working with people who didn't jump straight into industry as they seem to intuitively get this.
I've noticed many really talented programmers are ultimately cross-functional and don't care all that much for their "title". I would resist being labelled as one thing or another and instead focus on your skills and interests. "Software Engineers" need to know some statistics and how the models work while "Data Scientists" need to have baseline understanding of performance engineering and infrastructure.
Too often, people create their own moats and treat the other teams' work as a black box with some kind of coherent interface.
At Amazon scale this might be valuable, but for smaller companies working on a limited set of problems this wastes many synergetic optimisation opportunities and creates separate sub-cultures.
They say David Hilbert was the last mathematician to know all of mathematics, and it took hundreds (thousands?) of years to get there. Software and data science is a vastly simpler and newer field - I really don't think it should be surprising that the same person can write a C program and put together a UI in React.
Know thy tools
I've noticed that competent programmers really understand their build tools, package manager, text editor, programming language etc. It makes sense when applied to any other discipline - a sculptor who understands their chisel will probably be better than one who doesn't, as would a golfer who understands their putter. I think a lot of people go completely the other way and spend forever tuning their dot files, never use graphical debuggers, etc.
I personally find programming languages interesting and to some extent build tools, but not really the others. I'm personally not very ideological about these things.
Speed
Being 20% faster for some reason means you can be involved with far greater than 20% of the things (speed has super-linear returns). My working hypothesis is that this is because work has two distinct categories - one type is bursty and mostly reactive (think reviewing small pull requests, iterating on existing projects to add incremental functionality or fix a bug). The other kind is more deliberate and requires some design thinking, analysis or experimentation. This is when tackling new subjects or projects with many unknown factors. The quality of your decisions really matters here as they compound with time and complexity.
I personally think I lose a lot from context switching, and yet it is a necessary thing when you work on many things. One remedy is to be really fast at the former category of work to give you space to do the latter better.
The other component to speed is that it gives you more iteration cycles, which can mean improved quality.
Identify problems
Not all problems are created equal. Time is finite, so choose wisely. Seeing the long term trends and getting in early also seems to be valuable. It is more fun (and easier) to work on a greenfield project than iterating on a legacy codebase.
Solve problems other people won't touch
Do stuff other people don't want to touch. My experience is that tackling the tricky, unattractive problems no-one else cares about have been really great learning opportunities and almost always worth your time if you want to get better.
People may consider it outside their moat of expertise or somehow a skill that is not "valuable".
Re-evaluate assumptions
Occassionally people work on a side experiment that enables an entirely superior way to do something.
To be able to do this, you need to step back from time to time and re-evaluate the assumptions you have from scratch and synthesise in new knowledge and context.
It is hard to see beyond when in the weeds doing the reactive type of work only. It is also impossible to make educated decisions if you aren't aware of what is happening beyond the scope of the day to day.
I think this point also encompasses learning more broadly than the day to day. Become a Rust expert, learn OCaml, experiment with a new database, know how to exploit NumPy 2.0, etc.
It is impossible to connect the dots ahead of time but at some point it becomes applicable and you are positioned well to spot this and importantly to execute and do something non-iterative.
Fundamentally curious people have a good shot at this anyway but it is essential investment in the long run to be on the right point in the S-curve.
Reliability
My personal bias leaks in here. Having a reputation as a dependable person is very important. This transcends programming, but being able to execute well and in a consistently timely manner is a great way to build trust for the challenging problems.
If you say something will take two days but disappear for two weeks (and don't communciate well), or cannot operate independently, this is probably going to be a challenge and people won't want to work with you.
Fin
This article has rather narrow focus and hones in on technical competency for the most part. There is more to it. Having business-savviness, user-empathy and product orientation, an area of deep technical expertise, answering colleagues' questions, garnering trust, and probably a lot more I don't know about yet naturally factor heavily.
Back