Ask HN: Essential skill needed to be a programmer?
In the book Coders at Work by Peter Siebel, he asks peter norvig this question:
"So is there any essential skill needed to be a programmer? Different domains obviously have different requirements but ultimately is there some commonality to writing code regardless of domain?"
Peters answer to this _really_ resonated with me - his first two sentences were "You've got to be able to make progress and then improve on it. That's all you need to be able to do in life."
How would you answer this question?
192 comments
[ 3.2 ms ] story [ 214 ms ] threadWhat does that all boil down to? Probably curiosity, practically speaking. If you're genuinely interested in programming, and it's not just about money, status or proving some point, you'll be drawn to learn different things and have different discussions, over the whole course of your career, that will make you a good programmer, rather than just a passible coder.
Sincere interest is.
You can't be effective at your job if your manager sucks and you work with rude coworkers.
It depends on the problem domain. If you're writing low level code for a microcontroller that might require you to be able to do problemsolving on a whole other level than say writing CSS or arranging pre-built React components in a modern web application. In the same way styling those components might require a very different skillset in terms of taste, A/B testing etc.
I think it also helps if you have a skill for quickly deducing what's wrong when there is an error.
So being able to troubleshoot an error or bug quickly is my favorite coding super power.
Being able to Google a solution or something close to your coding problem/challenge and being able to adapt it and make it your own is a huge plus as well.
What I've found works better for me is identifying when things are barely starting to get ugly and calm myself. I tell myself that this suffering is temporary and remind myself I've been able to solve pretty much any problem I've faced.
I think this confidence is really important and part of it seems to come from having solved lots of problems in the past / working through frustrating periods. That's why "write lots of programs" is still my favorite piece of advice because it's a lot like "show up to the gym" if you want to get stronger.
Growing Google-fu is like getting good at smelling bad code, it takes experience, which you get via frustration and the application of gumption.
A curious thing that happens every time I write code is that some unexpected error occurs. Sometimes it's trivial stuff, other times it's deep structure. Either way, you have to be bothered to make changes and test them. Sometimes this tree gets very very deep. See an error, Google it, find an example that mentions a new keyword, explore that cave for a day, return to previous branch, etc.
Something about this is related to addiction, I think I'm somehow fortunate to be addicted to something useful rather than just some molecule.
To me, writing solid code is like combat.
At many times during the process the formation isn’t expressed in code yet, so it’s up to the mind of the programmer to keep the pieces fitting together as intended until the code can be written and take a little bit of the lift from the programmers brain to expressed code.
I draw on whiteboards, in moleskins, on printer paper, on the back of resumes... anywhere and everywhere. I do this because I need to convey complex ideas to important teams who are NOT programmers: Product, Marketing, People Ops, and the C-suite.
Helping people understand my ideas through illustration creates buy-in from them and trust in me. You can be a great programmer, but if people don't know and don't trust in what you're doing you'll never be given the space to execute.
Being able to clearly explain why your solution will solve a given problem better than the alternative and listen to your colleagues when their suggestion is better than yours, will save you an incredible amount of frustration. It is in my opinion the most important skill I have learned
- Asking why when debugging
Finding the code that's causing a bug is only the first step. The next is preventing a similar one happening again. By constantly asking "why was this choice made", you end up finding the actual weak points in both the code and your process. Whether it's because a hack some other place forced you to write another hack, that then failed or because there was a deadline so the commit was made at 3am, there is an important lesson to be had. If you combine that with good communication, you can talk to the team about changing things, so you avoid creating similar bugs in the future. (Pro-tip: 99% of bugs are there because there wasn't time to do things better)
I'd be happy to elaborate on that argument if you have any examples of one or more situations where you wouldn't consider communication important? :)
I think the difference for me is that the importance of communication for solo programming is a bit of a sliding scale depending on what your goals are. There aren't many exceptions when you work on a team. When I use the word importance, I'm tying it to a notion of necessity in relation to some goal. Team goals trump individual goals in organizations.
if you have no intention of making your code available for someone else to read / use / modify, the benefit for having readable code is really for yourself in six months and nobody else.
you also don't need to tell anyone what you're doing, so being able to clearly / succinctly explain what it is and why it's useful isn't a necessity. Does that make it an unimportant skill? No, it's just that the goals are different
I don't think I am able to explain it clearly without writing a very long post. There's a really good book by Marshal Rosenberg, titled non-violent communication, which gives a better explanation than I can right now. I would recommend it to pretty much anyone, if only for the very healthy way of treating oneself that it provides. Mileage may vary, but it fits my mental model pretty well
As an aside, I'm very glad to read through the replies to your post and see all the constructive you've engaged in. I've gotten mare than a few new thoughts and ideas because I chose to get involved in this post - thank you :)
Thanks for taking the time to engage! I've also learned quite a bit reading through everyone's responses.
For a very narrow definition of 'better', maybe. I'd argue most bugs are there because the cost of a bug is less than the cost of developer time it's take to prevent such bugs. There are industries where the cost of a bug is very high, but mostly bugs are like unemploymency rates: it's almost never economically feasible to get them down to zero.
Better is a subjective word, so I think I could have made my point more clear by instead writing "99% of bugs are there because there wasn't allocated enough time to prevent them"
Do you agree more with that statement than the one I originally posted? :)
You make it seem more planned and reasoned out than it really is. I mean, you can make a meta-argument, that market evolution and pressures push things towards that optimal cost-benefit spot, but on the micro scale it often just happenstance.
Again, the meta-argument can be that even doing the cost-benefit analysis is not worth the cost, but it's quite handwavy.
What counts as "better" anyway? From the engineering perspective it's about efficiency, bug-freeness, elegance. From the company perspective, profits. From the manager perspective, looking good and getting promoted.
You can often game the system by rushing a subpar product out the door, downplaying and not even caring about the defects, wooing customers into buying in with clever sales tactics and marketing, then moving on before things start crumbling down. In some sense this was worth it in terms of your personal costs and benefits and all was done in the best possible way.
If you think about it, software is driven by business requirements in most cases. But business requirements are open to interpretation. How do we know what people really want? This comes down to good communication.
1. All kinds of things that you never considered go wrong all the time. This trains you to consider what could possibly go wrong in the long term deeper and ever deeper. I find this carries over into non-coding activities.
2. You are continuously faced with problems that seem completely unsolvable. And, you keep solving them day in and day out for decades. This trains you to be (perhaps rationally) optimistic about what can be done. Because every problem starts out devoid of clues and devoid of clear ways to get clues. No idea what's happening or even where to look. But, it always turns out to be something! It's never evil magic. You might be left with the mystery of "How did this ever work?" But, you solved it. You committed the 3-line patch that took 3 days to write. And, you'll move on to the next unsolvable problem right after lunch.
But, I don't think this is the main skill in programming. Good programming is the iterative application of concision and honesty, tempered by the ability to interrupt overfocus so as to find the right balance between perfection and getting something done.
After the inception of stackexchange, the ability (or motivation) to read man pages seems to have have plummeted.
To be a good programmer, if I have to pick only one "skill" I would pick systemic thinking/understanding. This starts with the ability to learn and eventually understand how a system works. The next level is the ability to create a working model of that system in ones mind. Someone who can do that will be very successful at programming anything in any language on any platform given sufficient documentation.
I agree - so much of our time is spent coming up with working models of systems
I wonder how many people have this ability, especially when reading about organizations like the one that went to Appalachia to teach people in depressed areas to program.
I was going to phrase it as "simultaneously seeing the forest and the trees."
The vast majority of my programming career has involved (1) taking a huge amount of information (specs, code), (2) building a mental model of it at 2+ levels of detail (high-level to fit a simplified holistic system in my mental swap space, and detail to have all the details about this problem at hand), (3) identifying the needle in the haystack, & (4) coming up with a simple solution.
As the parable goes [1], it's knowing which bolt to turn & how far.
[1] https://www.snopes.com/fact-check/know-where-man/
I saw many beginners who treat a compiler like a black box and attempting hand fuzzing until it happened to match the well-formed syntax and behaviour they wanted, while they literally holding a paper text book or opening a browser tab for a tutorial which clearly explain how it works and what they should write in a plain natural and native language of theirs.
One time, I was told by a beginner who copied an example code from a text book that it doesn't work. I looked at it. It was a fizzbuzz code, less than 10 lines. And she typed it wrong. Not just an ordinary typo. She conjured up really strange ill-formed syntax she believe it works somehow. There is a parse error message but she ignored. I pointed out the place on display with a finger and she still didn't get it. I place a text book beside the display but it requires a considerable effort convincing her the cause of the error.
Other time, I was asked why for(;;) ; else ; doesn't work in JavaScript. I kept saying because there is no syntax like that in JavaScript. You have to accept it as is or create your own language.
Sometimes, I wonder some people read natural language text by simple keyword pattern matching. People like above example weren't dumb. Far from it. They are smarter in their field than me. Yet, they failed at this basic literacy level.
That's not all you need, obviously. No one thing is the magic bullet which will make you a better programmer. But the worst programmers I've worked with only write code which works on their machine, for their specific use-case.
If you're just trying to be a hobbyist and do stuff for fun then I'd say you need some things that aren't necessarily skills like curiosity, a love of challenging problems, and ability to easily retain information that you read.