Ask HN: Essential skill needed to be a programmer?
192 comments
I consider this essential:
The ability to decouple the task from your ego.
Specifically:
- Never say "Got it" or "OK" when someone is explaining a problem or solution and you don't follow. It feels awkward to say "Sorry, I'm still not following. Do you mean that when..." five times in the same conversation but it is worth your time and embarrassment to come away with a correctly framed and well understood situation. Otherwise you will figure out what they meant after wasting hours/days/months solving the wrong thing.
- You'll be faced with situations where your colleagues/organization expect you to implement solutions you think are not the best. Understand that "the best way" for the team or business is not necessarily the same as "the best way" for you personally or "the best way" overall. You are likely missing some context about the choice. Be mindful of reputation risks, time costs and maintenance costs involved in changing the approach.
When you're asked to code something you don't agree with (including ethical issues) your options include: silently accept their approach, refuse to do their approach, propose an approach (with conversation or code) and gracefully accept the result, or find another job. Be aware that different organizations will react differently to those approaches. Under no circumstances should you fall into the trap of spending a week to convince the team to adopt a change that would save a week of costs.
Specifically:
- Never say "Got it" or "OK" when someone is explaining a problem or solution and you don't follow. It feels awkward to say "Sorry, I'm still not following. Do you mean that when..." five times in the same conversation but it is worth your time and embarrassment to come away with a correctly framed and well understood situation. Otherwise you will figure out what they meant after wasting hours/days/months solving the wrong thing.
- You'll be faced with situations where your colleagues/organization expect you to implement solutions you think are not the best. Understand that "the best way" for the team or business is not necessarily the same as "the best way" for you personally or "the best way" overall. You are likely missing some context about the choice. Be mindful of reputation risks, time costs and maintenance costs involved in changing the approach.
When you're asked to code something you don't agree with (including ethical issues) your options include: silently accept their approach, refuse to do their approach, propose an approach (with conversation or code) and gracefully accept the result, or find another job. Be aware that different organizations will react differently to those approaches. Under no circumstances should you fall into the trap of spending a week to convince the team to adopt a change that would save a week of costs.
I've never mentally dinged someone for saying they don't know how to use a particular technology. This field is immense and there is no possible way for any person to understand it all.
But when someone said they could do something a particular way and the results suggest otherwise I find it completely frustrating.
But when someone said they could do something a particular way and the results suggest otherwise I find it completely frustrating.
It's extremely hard to prove things in programming.
You can either develop both options and pick the best, or you can use "best practices", which is non scientific. Authority and tradition make best practices.
Also "don't @ me" about basic logic like nested loops and bigO. That's not what I'm talking about here.
You can either develop both options and pick the best, or you can use "best practices", which is non scientific. Authority and tradition make best practices.
Also "don't @ me" about basic logic like nested loops and bigO. That's not what I'm talking about here.
>> You are likely missing some context about the choice
If it's a product/business decision and you care about that aspect of your work, dig down and understand the context, otherwise, before long you're likely to grow numb to that aspect of your work.
If it's a product/business decision and you care about that aspect of your work, dig down and understand the context, otherwise, before long you're likely to grow numb to that aspect of your work.
This 1000%. If you're in a business-interactive role, ask about the business as time permits.
People like to feel like an expert, and will usually be happy to explain.
It will make you better (knowledge transfer to unrelated problems), your code better (domain knowledge), and your relationships better (recognizing your colleagues as peers with different skills, not just not-your-skills).
People like to feel like an expert, and will usually be happy to explain.
It will make you better (knowledge transfer to unrelated problems), your code better (domain knowledge), and your relationships better (recognizing your colleagues as peers with different skills, not just not-your-skills).
Agreed. understanding the problem is a big thing. Then explain it back to them, perhaps offer them a better solution if you can.
Asking questions is the way to understanding.
Asking questions is the way to understanding.
This. I immediately develop deeper respect for a colleague when they interact with me this way. (Assuming it's not me who's not following - that happens plenty too!). When a colleague, including junior devs, ask questions and dig in, I interpret that as thinking critically about the problem and digging in. That's exactly what I want out of engineers.
Most coders I see give up on asking clarifying questions because they realize quickly that the answers aren’t there, and they never will be, and this is somehow okay to the person who is telling them what to do.
It’s really obvious during remote work: PowerPoint then silence, then a bunch of assignments handed out. If you ask any one of the audience, coder to coder, they all have the same confusions; some write a fancy class template like ‘ProblemSolverObjectDispatchFactory’, others just ignore.
It’s really obvious during remote work: PowerPoint then silence, then a bunch of assignments handed out. If you ask any one of the audience, coder to coder, they all have the same confusions; some write a fancy class template like ‘ProblemSolverObjectDispatchFactory’, others just ignore.
That doesn't seem specific to programming. You could say the same thing about mechanical engineering for example.
> Never say "Got it" or "OK" when someone is explaining a problem or solution and you don't follow.
The absolute worst is when a colleague does this on your behalf.
The absolute worst is when a colleague does this on your behalf.
Absolutely.
As a front end developer your existence is ultimately defined by your grasp of very few tree models, namely the DOM but also the file system and various similar concepts when writing systems automation. It is common for developers to not grasp the concept of implicit relationships, which are a fundamental consideration of tree models.
This is basic stuff, the foundation that defines your career. And still many developers do not grasp it. They spend so much of their careers hiding from the core concepts of their jobs dependent upon abstractions to reframe the technology.
What may begin as embarrassment evolves into stubborn resolution masking extreme insecurity. Everybody can see when you are embarrassed, insecure, and when you fail to understand something. So many times people will try to redefine an important problem to appear less lost or hopeless. When other people are really listening they can see through it. It’s only a shallow self-deception.
It’s okay to not know something and need help. Pretending otherwise is poor character.
As a front end developer your existence is ultimately defined by your grasp of very few tree models, namely the DOM but also the file system and various similar concepts when writing systems automation. It is common for developers to not grasp the concept of implicit relationships, which are a fundamental consideration of tree models.
This is basic stuff, the foundation that defines your career. And still many developers do not grasp it. They spend so much of their careers hiding from the core concepts of their jobs dependent upon abstractions to reframe the technology.
What may begin as embarrassment evolves into stubborn resolution masking extreme insecurity. Everybody can see when you are embarrassed, insecure, and when you fail to understand something. So many times people will try to redefine an important problem to appear less lost or hopeless. When other people are really listening they can see through it. It’s only a shallow self-deception.
It’s okay to not know something and need help. Pretending otherwise is poor character.
Thinking. It's the _only_ skill programmers need. Everything else will follow.
Just thinking is not enough, you also have to be attentive. Yet another essential skill is to hear and see what is really there and not what your mind tricks you into seeing.
Most anyone can learn how to write code, however adding different skills can increase both the quality of what you produce, and the breadth of problems you can solve. You don't "need" to learn things like program complexity, but knowing it can help you write more efficient programs; you don't need to know math, but it helps if you want to work with encryption, and in a way testing, too.
What 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.
What 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.
No particular skill is needed.
Sincere interest is.
Sincere interest is.
I've met plenty of programmers who had no sincere interest, but just saw it as a job they did 9-5 and then never thought about computers outside of those times. Programming was simply seen as a skill that could lead to comfortable, reasonably well paid job, and that was all the incentive they needed to learn the minimal amount needed to get said job. Basically as long you have an incentive to want to learn and a bit of tenacity you almost certainly can.
This would be the worst job ever if I didn't love it. I can't imagine doing it otherwise.
I don't especially enjoy my work, but the people I work with are decent and it pays the bills.
Yeah, there are so many different motivators for work. I really enjoy programming as a hobby, but I also wish we would stop treating that as if it's a pre-req to doing good work.
You can't be effective at your job if your manager sucks and you work with rude coworkers.
You can't be effective at your job if your manager sucks and you work with rude coworkers.
I quite enjoy programming new stuff from scratch, but most of the time my job is keeping other peoples crappy code running.
I had a friend who said he would never consider this type of work because there's way too much sitting... and I'm like wow that's actually one of the _easiest_ problems to solve!
Being able to memorize things.
i've come to appreciate how useful it is to just remember basic stuff from stlib instead of having to look things up. Makes getting into flow much easier.
Programming as a whole is too wide to have a single answer.
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.
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.
y, just being able to take the plunge and try, innovate and improve is the first step.
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.
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.
working in teams
There are many skills (curiosity, persistence, willingness to improve, etc) but IMO the most essential is being able to deal with your own frustration.
when I get frustrated that's often a cue for me to take a break haha. It's been a nice way to deal with frustration for me.
For years I couldn't recognize when I was starting to get frustrated and kept pushing until it was too much to bear.
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.
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.
> 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.
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.
Google hacking or Google in general is very useful
Learning what questions to ask into Google is a critical aspect. Most of the time, coding is the process of writing some code, and then debugging it. Knowing to ask, my graphql endpoint is failing with a status of 500, vs. my graphql doesn't work. The first will help you narrow down the issue, the second is far too generic. I have been coding for over 20 years now, and I feel it is rinse and repeat in terms of hitting a roadblock, and finding the answer. Also, a lottttttt of patience. You might take two hours to figure out something that ends up being really trivial, and then you have that moment of feeling good that you solved it, and then you are right back into the next hurdle.
Google falls down flat unless you know "magic words". Example... let's say you want to be able to mark up a web page to highlight some aspect of it, like using a highlighter on a newspaper... you can't google hypertext markup... you have to go for "annotation"
Growing Google-fu is like getting good at smelling bad code, it takes experience, which you get via frustration and the application of gumption.
Growing Google-fu is like getting good at smelling bad code, it takes experience, which you get via frustration and the application of gumption.
I've noticed myself scrolling farther and farther down search results. There's so much SEO'd garbage at the top of the fold now.
Tenacity is the short version of what Norvig is saying.
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.
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.
Couldn't agree more. You might be highly intelligent and/or creative, and those things should help for sure, but if you don't have grit, nearly a masochistic attitude to keep striving when you're flat on the ground or when you're at a dead-end, you won't make it.
To me, writing solid code is like combat.
To me, writing solid code is like combat.
Critical thinking is the most essential skill in my opinion to be a good programmer
It’s applied problem solving. I often think of programming as invisible legos that you put together that build some sort of Rube Goldberg machine.
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.
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.
The single greatest benefit to my career as a developer has been learning to draw.
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.
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.
What level of drawing we talking here?
- Communication skills
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)
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 don't know the sense of OP, but there's a difference between 'programming' and 'software development'--the latter is done in a team. Often the terms are used interchangeably but the skills to make one a good solo software writer only overlap with developing in a group.
I agree with the difference between programming and software development, though I'm not entirely sure on why you're pointing this difference out. Do you think my answer is not answering the OP's question? :)
I intended it to be pretty open ended. Mostly interested in skills that are useful for _both_ solo and team work. I agree that there are some things that can be very useful for team work that are not as essential for solo work when it comes to programming. For example, being able to justify technical decisions to higher ups. Lots of communication skills are essential for teamwork.
The examples I gave obviously requires being part of a team, but even programming on your own, I think it's one of the most important skills.
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'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 totally agree - I think I'm probably coming off as disagreeing with you though.
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 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 would extend the term "communication" to also include how we speak and listen to ourselves
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 :)
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 :)
Ah, I see. Thank you for clarifying that. That book sounds interesting, I'll check it out.
Thanks for taking the time to engage! I've also learned quite a bit reading through everyone's responses.
Thanks for taking the time to engage! I've also learned quite a bit reading through everyone's responses.
>99% of bugs are there because there wasn't time to do things better
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.
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.
I think we're saying the same thing in two different ways, so I agree with your point. What I'm reading is a good "why" - why wasn't there time to prevent this bug.
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? :)
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? :)
> I'd argue most bugs are there because the cost of a bug is less than the cost of developer time
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.
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.
the ability to communicate well is an essential skill.
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.
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.
Pessimism. Expect everything that can fail to fail and code defensively to deal with it gracefully. Doesn't make you much of a joy to work with though
haha there's a man thats been doing this for a long time. Every bug I have is an 8 man meeting (me being the only one who actually does anything) to explain why my TPS report cover wasn't there and how we can prevent bugs in the future.
reminds me of http://threevirtues.com/
Programming is a funny mix of deep pessimism and irrational optimism. After coding for a long time, you see two themes continuously and they train your behavior:
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.
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.
For me, this is the attitude that there is always something wrong with the code, there are always errors, and it's a question of whether I've found enough errors so the program is sufficiently reliable.
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.
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.
Core skill: Being able to read and write documentation.
After the inception of stackexchange, the ability (or motivation) to read man pages seems to have have plummeted.
After the inception of stackexchange, the ability (or motivation) to read man pages seems to have have plummeted.
To simply be a programmer, one must only write a program, nothing more. The essential skill I guess would be literacy, knowing how to read and follow directions, knowing how to use a keyboard, not much.
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.
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.
literally true!
I agree - so much of our time is spent coming up with working models of systems
I agree - so much of our time is spent coming up with working models of systems
i always call this exact distinction the difference between programmer and software developer. in my case, actual programming is 10% of the time, maybe 20% if you count staring at logs and/or monitoring trying to figure out what the hell happened. interns do the most programming since that's the easy part, the hard part is figuring out what interns should program next.
Yep, the ability to construct a mental model is the most critical. If you can then keep it organized when you translate it to code, I'd say you're well-suited to the work.
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 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.
> systemic thinking / understanding
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 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/
Yes. Literacy.
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.
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.
I've focused on learning on a want/need to know basis. This has allowed me to make things I want or get paid to make, but I think you nailed the "essential skill" spot on.
Empathy. You need to be able to empathise with the user. That user might be the person giving you requirements. The person using your product. The user reading your code in a year's time.
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.
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.
Communication is probably the biggest skill needed if you're trying to be an employed programmer working on a team.
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.
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.
One issue with learning to program,many people think learning the syntax of a particular language is programming.
The one thing all programmers need is a way of thinking about problems and systems.
Hard to teach.
You gotta be smart and able to think abstractly. You are building virtual legos and keeping that all suspended in your brain and that's hard to do. I hear people throwing out general terms like literacy and communication. Not really. There's a certain type of brain that's built for programming if it comes easy to you. If it doesn't come easy just bail now.
Discipline. It powerfully affects code and documentation quality, time management, operations, and interpersonal relations, just to name a few.
Proper literary training. With it comes memorization skills, structuring of ideas, comprehension of abstraction, naming and defining skills.
The ability to focus for extended period of time is important and well known.
I think that good programmers also have a better than average short-term working memory space, so they can keep relatively complex structures in their head.
I think that good programmers also have a better than average short-term working memory space, so they can keep relatively complex structures in their head.
I'll second this one because it's the first thing I came up that wasn't just some generic advice.
The worst feeling for me in programming is not knowing 'where' I am in the code, when everything just feels like some sort of mental mush and you just stare at code confused because it's clogged your head up.
It's really good to be able to really focus, rearranging things in your head, imagining how something might look before it's done and so on.
The worst feeling for me in programming is not knowing 'where' I am in the code, when everything just feels like some sort of mental mush and you just stare at code confused because it's clogged your head up.
It's really good to be able to really focus, rearranging things in your head, imagining how something might look before it's done and so on.
programming is most like looking at a lego set and being able to figure out the instruction working backward.
problem decomposition is maybe not the central skill, but the one that helped me most so far.
problem decomposition is maybe not the central skill, but the one that helped me most so far.
Willingness and ability to learn and to never stop learning.
- Understanding cache hierarchies
- Selecting good names
- And thinking straight forward, being able to count from zero to one and two and so on.
And no, it is not just a joke, but my actual opinion, that understanding the underlying machinery, communicating well, and being to able to think on your own through complicated matters are the most valuable skills in programming.
[edited layout]
- Selecting good names
- And thinking straight forward, being able to count from zero to one and two and so on.
And no, it is not just a joke, but my actual opinion, that understanding the underlying machinery, communicating well, and being to able to think on your own through complicated matters are the most valuable skills in programming.
[edited layout]
By essential, it is what most engineering disciplines have in common:
Good logical reasoning, and spatial thinking/skills, ability to build up complex systems from smaller ones, and ability to understand/debug how complex systems work, and no 'magical thinking', but ability to analyze things logically.
I am seeing here a bunch of answers that mention 'communication', 'write docs', etc... etc but those are essential skills for any employee in a large company, no matter what the discipline is.
They are not core engineering skills per se (though they are necessary to perform in a large company). If you can't code, or don't understand concepts your communication skills will not help you that much. Maybe become a PM, or some kind of manager, but not an engineer.
P.s I know communication is not core, as i have worked with many 'brilliant' engineers that they had poor communication skills due to be foreigners, or just personality quirks. While that will hamper their ability to get promoted to managers, or architects, they all were respected and did well as engineers.
Good logical reasoning, and spatial thinking/skills, ability to build up complex systems from smaller ones, and ability to understand/debug how complex systems work, and no 'magical thinking', but ability to analyze things logically.
I am seeing here a bunch of answers that mention 'communication', 'write docs', etc... etc but those are essential skills for any employee in a large company, no matter what the discipline is.
They are not core engineering skills per se (though they are necessary to perform in a large company). If you can't code, or don't understand concepts your communication skills will not help you that much. Maybe become a PM, or some kind of manager, but not an engineer.
P.s I know communication is not core, as i have worked with many 'brilliant' engineers that they had poor communication skills due to be foreigners, or just personality quirks. While that will hamper their ability to get promoted to managers, or architects, they all were respected and did well as engineers.
old, but ever-green:
Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of ‘meaningless’ detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains.
http://www.catb.org/jargon/html/personality.html
Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of ‘meaningless’ detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains.
http://www.catb.org/jargon/html/personality.html
Lots of people have put less obvious skills required, but IMO a decent level of logical thinking is a definite requirement. I think we often take this for granted because most of us who make a career out of programming find it so easy, but I've never seen anyone succeed at programming unless they had this.
3 things: 1) curiosity 2) learning 3) growth
you need to be curious about why things in a certain way or why they don’t work, to take them apart, to continuously ask why
along with curiosity you need to learn. ALL THE TIME. you job learning is never done. there are fundamental things that will not change with time but a lot of things will and mastering anything will be a lot of work.
and last: growth. you need to tackle bigger and bigger problems and understand more and more in order to not get into a dead end career-wise. your goal is that by learning basic building blocks (programming languages, frameworks, tools) you get to work on or learn more advanced building blocks. the abstraction level you work on should go up
you need to be curious about why things in a certain way or why they don’t work, to take them apart, to continuously ask why
along with curiosity you need to learn. ALL THE TIME. you job learning is never done. there are fundamental things that will not change with time but a lot of things will and mastering anything will be a lot of work.
and last: growth. you need to tackle bigger and bigger problems and understand more and more in order to not get into a dead end career-wise. your goal is that by learning basic building blocks (programming languages, frameworks, tools) you get to work on or learn more advanced building blocks. the abstraction level you work on should go up
Abstraction.
When my kids were little I thought I would teach them programming. The biggest problem I had was teaching them what a variable was. They finally did figure it out after a lot of work.
Abstraction is the same barrier between elementary school math and algebra. Some people never do learn algebra.
When my kids were little I thought I would teach them programming. The biggest problem I had was teaching them what a variable was. They finally did figure it out after a lot of work.
Abstraction is the same barrier between elementary school math and algebra. Some people never do learn algebra.
English, for those of us not born into it.
Thinking abstractly with a sense of curiosity and humor. Only hire programmers who like Monty Python.
Second would be the ability to write a one-page summary of problem and proposed solution.
Second would be the ability to write a one-page summary of problem and proposed solution.
The Monty Python test. Also, Spaceballs.
Just "to be a programmer"? Frustration tolerance. Thats pretty much it.
To be a good programmer: very much depends on your area of expertise. Most of them need good communication skills, some machine-level understanding, some math or algorithm skills, some require high velocity / long hours... It really is a very diverse field.
But like for most jobs, frustration tolerance gets you surprisingly far.
To be a good programmer: very much depends on your area of expertise. Most of them need good communication skills, some machine-level understanding, some math or algorithm skills, some require high velocity / long hours... It really is a very diverse field.
But like for most jobs, frustration tolerance gets you surprisingly far.
Gladwell's book Outliers held this theory that the people who learned to be good at math are the ones who sat down long enough to see it through. It took about 22 minutes for someone to learn a basic fundamental of math. Most people give up by 2-5 minutes. Programming is a lot like that. Arguably those with good algorithm skills and such have even higher frustration tolerance.
I successfully turned my mom from someone who often needed computer help, into someone who was pretty self-sufficient, when I told her that "The solution to any technology problem will only have two ingredients: Google and pain. If you have access to the first, you can solve anything provided you're willing to endure enough of the second."
Outstanding move.
I've a MSc in Computer Engineering and I think the most important stuff I learnt are "Design Patterns" and in general any Principle that guides you to write code that is: flexible, clean, maintainable, efficient and reusable.
Any programmer can write code, but how many can meet the requirements mentioned?
Put another way, it's easier to write a throwaway program that works once but how do you make it continue to work and serve needs over some period of time? I think part of it is knowledge of principles like you said, but I also don't think there's a substitute for experience because the real world is messy and principles sometimes need to be intentionally broken.
Programmers and problems come in a bunch of varieties. Some programmers only need to solve a small subset of problems, so understandably their skill set doesn't need to be particularly broad. It's ok to be capable in a niche area if that brings value to you or your organization. Largely though, programming does come down to problem solving.
The best programmers have an eye for detail that can see below the surface of a system. When someone says "we need feature X because Y", they take a Socratic stance and ask "Why do they believe X will solve Y? Why is there a Y? Is there also a Z or a W to consider?" These aren't necessarily coding questions, they're engineering and process questions. Anyone with some familiarity with a system and the tools can add feature X, but the best developers will think about the precursors and implications of X first in hopes of improving the system as a whole.
The best programmers have an eye for detail that can see below the surface of a system. When someone says "we need feature X because Y", they take a Socratic stance and ask "Why do they believe X will solve Y? Why is there a Y? Is there also a Z or a W to consider?" These aren't necessarily coding questions, they're engineering and process questions. Anyone with some familiarity with a system and the tools can add feature X, but the best developers will think about the precursors and implications of X first in hopes of improving the system as a whole.
A high tolerance for frustration helps.
"The want to create something"
The ability to learn and adapt. The first few years as a programmer you are going ton have a billion aha! moments. At every turn you will think you are a bad ass, only to be humbled. Have an open mind ready to learn and adapt.
Curiosity, playfulness and no fear of the machine.
The ability to write down in a few sentences what you're actually trying to do. The number of people who can't frame the problem they're trying to solve is unbelievable.
Alan Perlis epigram #32: http://www.cs.yale.edu/homes/perlis-alan/quotes.html
"Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis."
Well-engineered programs cover all the cases: they handle what they must handle, and have an answer for the rest which is better than "oh shoot, didn't think of that".
The main programmer skill is remembering to ask yourself, "under what conditions won't this work?" or "what inputs or situations break this?" and being able to come up with excellent answers.
Also, asking this question: "though this appears to work, where are all the requirements (language, library, platform, ...) coming from which make it work, and are any missing?"
"Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis."
Well-engineered programs cover all the cases: they handle what they must handle, and have an answer for the rest which is better than "oh shoot, didn't think of that".
The main programmer skill is remembering to ask yourself, "under what conditions won't this work?" or "what inputs or situations break this?" and being able to come up with excellent answers.
Also, asking this question: "though this appears to work, where are all the requirements (language, library, platform, ...) coming from which make it work, and are any missing?"
Critical thinking. The ability to evaluate ideas against reality and reject them if they don’t match.
Curiosity, Fearless, and Listening skils.
The IT industry doesn't really need "programmers". It needs people who build quality software systems. There is a difference.
The essential skill to look for is the ability to imagine some system working differently from how it works right now. A good engineer should be able to imagine several novel, alternative states and compare them, thinking of various consequences and trade-offs.
The essential skill to look for is the ability to imagine some system working differently from how it works right now. A good engineer should be able to imagine several novel, alternative states and compare them, thinking of various consequences and trade-offs.
There are plenty of cases where some shitty code will bring value to a company or person. Most junior programmers don't build stuff that is especially good.
In order to be successful programmer you need a lot persistence and patience.
Plus having a long term vision is a must
Maybe not essential, but definitely useful: Abstract thinking and visualization.
Being able to create mental metaphors of systems or problems, solve the metaphors and apply the solution to the original problem.
Being able to create mental metaphors of systems or problems, solve the metaphors and apply the solution to the original problem.
I'm not sure if this really qualifies a skill. How do you improve it?
I'm an outside consultant and I'm often called to fix stuff that other outside consultants built. Pretty much 100% of the time, I am there because somebody was lacking in attention to detail. Whether it is a misplaced semicolon or a 100mbit interface in a virtual switch or some doodad doing a TCP handshake in the wrong order, I think over half of the 'edge cases' that make it to me are because somebody did not cross their Is and dot their Ts.
I think that good attention to detail is essential not just in programming or systems, but every technical profession.
I'm an outside consultant and I'm often called to fix stuff that other outside consultants built. Pretty much 100% of the time, I am there because somebody was lacking in attention to detail. Whether it is a misplaced semicolon or a 100mbit interface in a virtual switch or some doodad doing a TCP handshake in the wrong order, I think over half of the 'edge cases' that make it to me are because somebody did not cross their Is and dot their Ts.
I think that good attention to detail is essential not just in programming or systems, but every technical profession.
It's like asking how to become a cook. There's just so much variety to it - it could be hobby, professional, corporate, or artisanal, etc. You can't give any more specific answer to that.
[deleted]
Sitzfleisch
Building on Peter's answer, I've always strived for three things: Better, Faster, Cheaper.
Better: I try to build things that are sturdier, more beautiful, and solves the problem better.
Faster: Each time I build something, it has to be done faster. Code is faster to read, modify, replicate. Code functions more predictably and is quicker to debug.
Cheaper: I'll keep charging more, but it will cost less. A fresh graduate might do the same for $2000/month, 3 months. I try to get it done in $9000/month, 10 days. Part of this is not spending too much time on something that might be scrapped later, knowing when to plan ahead and when not to.
The essential skills are not really math or writing. Some of it is raw technical ability - know when and how to use reactive programming, declarative, imperative, and so on. Sometimes it's leadership, speaking up when you're stuck or something looks pointless. Sometimes it's just knowing how to learn and unlearn, and how to filter out the golden bits of knowledge from the sea of useless, self-promoting articles and books out there. And it seems trivial, but one of the skills that lets you do all three is knowing how to type 20 WPMs faster and use keyboard shortcuts.
Better: I try to build things that are sturdier, more beautiful, and solves the problem better.
Faster: Each time I build something, it has to be done faster. Code is faster to read, modify, replicate. Code functions more predictably and is quicker to debug.
Cheaper: I'll keep charging more, but it will cost less. A fresh graduate might do the same for $2000/month, 3 months. I try to get it done in $9000/month, 10 days. Part of this is not spending too much time on something that might be scrapped later, knowing when to plan ahead and when not to.
The essential skills are not really math or writing. Some of it is raw technical ability - know when and how to use reactive programming, declarative, imperative, and so on. Sometimes it's leadership, speaking up when you're stuck or something looks pointless. Sometimes it's just knowing how to learn and unlearn, and how to filter out the golden bits of knowledge from the sea of useless, self-promoting articles and books out there. And it seems trivial, but one of the skills that lets you do all three is knowing how to type 20 WPMs faster and use keyboard shortcuts.
A mental model I use all the time when programming is "Chesterton's Fence" (When removing a fence, you must know why the fence was placed there in the first place).
When making changes to an existing system (whether its adding new functionality, extending existing functionality, or refactoring the code while maintaining existing functionality), try to understand the intent behind the current structure of the code and why certain design choices were made.
Once you understand that, you can add new features/extend existing features using the same design OR refactor the code with a new design without impacting existing functionality (assuming you don't have universal test coverage... which frankly will be the case a lot of the time).
Another tactic I use is verbalizing my design choices before/during the implementation of a feature/product. When programming, a lot of developers create a mental structure/map of the code base and what changes they are implementing. They know the changes they are making in their mind and know how to execute them. However, if they were to explain what they were doing to another developer (for collaboration, handoff, etc) or to business/product (ie. in order to explain estimations), they freeze up. Verbalizing your design choice will strengthen your technical communication skills.
Those 2 things aren't necessarily skills, but they are tactics that can be used to be a better programmer.
When making changes to an existing system (whether its adding new functionality, extending existing functionality, or refactoring the code while maintaining existing functionality), try to understand the intent behind the current structure of the code and why certain design choices were made.
Once you understand that, you can add new features/extend existing features using the same design OR refactor the code with a new design without impacting existing functionality (assuming you don't have universal test coverage... which frankly will be the case a lot of the time).
Another tactic I use is verbalizing my design choices before/during the implementation of a feature/product. When programming, a lot of developers create a mental structure/map of the code base and what changes they are implementing. They know the changes they are making in their mind and know how to execute them. However, if they were to explain what they were doing to another developer (for collaboration, handoff, etc) or to business/product (ie. in order to explain estimations), they freeze up. Verbalizing your design choice will strengthen your technical communication skills.
Those 2 things aren't necessarily skills, but they are tactics that can be used to be a better programmer.
I would say humility is the most crucial skill. If you can't admit when you're wrong or you lose your mind when peer reviewed, you are going to find yourself in more trouble than working correctly in a team setting. It also allows you to question your own code to confirm if it's the existing code or yours (usually whatever is new is broken, not always, but usually there's a high probability). I have had coworkers that have lacked simple humility and self-destruct verbally when you question their code, and I've heard of coworkers having worked with people that will never admit to their code being wrong until you point to the exact line and the change they need done to fix the issue.
You waste more time defending something that will always need updates and fixes than you do getting things done when you lack humility. It is something I learned early on and I hope more developers learn it.
I will take a 'good enough' dev with a wonderful personality over an above and beyond developer with the most toxic personality any day of the week, unless I'm under an extremely tight deadline. A toxic developer can poison a whole team and ruin their productivity.
You waste more time defending something that will always need updates and fixes than you do getting things done when you lack humility. It is something I learned early on and I hope more developers learn it.
I will take a 'good enough' dev with a wonderful personality over an above and beyond developer with the most toxic personality any day of the week, unless I'm under an extremely tight deadline. A toxic developer can poison a whole team and ruin their productivity.
Humility impacts cooperation, but another side of it is that it impacts learning. In order to learn you need to believe that you got something to learn, and that is not happening often in people too full of themselves.
I think that largely depends on what kind of programmer you are. Like it or not, systems development, app development, backend, frontend, integrated circuit development all have their own mindset and associated challenges and skills. What is your most essential skill? the drive to learn.
Yeah - I think that drive to learn and improve also directly relates to what peter norvig touches on.
I think a big part of _keeping_ that drive if you have it (or cultivating that drive if you don't) requires a sort of being able to experience delight / happiness from learning new things. Even the little things.
Like today, I learned a tiny shortcut in writing rails routes. Not a huge game changer obviously, but little things like that make me smile!
I think a big part of _keeping_ that drive if you have it (or cultivating that drive if you don't) requires a sort of being able to experience delight / happiness from learning new things. Even the little things.
Like today, I learned a tiny shortcut in writing rails routes. Not a huge game changer obviously, but little things like that make me smile!
As with everything in life: Get your ego out of the way.
People tend to identify themselves with technology they mastered and miss out on all the improvements that happen. This works for a few decades if they're lucky, but someday they're old and wonder why nobody values their skills in an obsolete technology.
We can't all maintain Cobol code bases when we are 50.
People tend to identify themselves with technology they mastered and miss out on all the improvements that happen. This works for a few decades if they're lucky, but someday they're old and wonder why nobody values their skills in an obsolete technology.
We can't all maintain Cobol code bases when we are 50.
I hope you are aware that 50 year olds started working 1990 to 1995 or even later, when there was a lot more than just COBOL going on.
In fact, a 50 year old is more likely to have caught the rise of desktop GUIs and of Linux than have spent a career doing COBOL.
In fact, a 50 year old is more likely to have caught the rise of desktop GUIs and of Linux than have spent a career doing COBOL.
I know.
It was a joke that targeted the argument: "You know that old tech is still in use? Look at all the COBOL used in industry XYZ."
It was a joke that targeted the argument: "You know that old tech is still in use? Look at all the COBOL used in industry XYZ."
This is so easy to forget. I think when we're in the trenches it's quite hard to pull back and view what you're doing as means to an end and the means (libraries, frameworks) change constantly.
I think it's also difficult in practice because it feels good to master things in general. It's a nice feeling to know that you know a system inside and out, so detaching from that is going to be hard no matter what especially if you've invested quite a bit of your life into it
I think it's also difficult in practice because it feels good to master things in general. It's a nice feeling to know that you know a system inside and out, so detaching from that is going to be hard no matter what especially if you've invested quite a bit of your life into it
The tech skills that I think are critical to a software dev:
Git and version control, learn them as in depth as you have time for. Every decent dev environment has these and the amount of people lacking this basic knowledge is staggering.
Bash/Linux or powershell/windows same thing. You can get an amazing amount of things done with shell scripting in your OS. Unless you have an insane amount of time I would pick one and learn in depth. These are rich systems.
A dynamic programming language in depth. There are so many concepts that will transfer between languages that if you know one in depth, you'll be able to pick another one up pretty fast as it's just semantics at that point.
SQL, this is an essential part of dev life and you will understand ORMs and data management better.
The personal skills:
Communication obviously. This is such a vague term and I think is abused as people just say 'lERn to CoMmUNicate' with no actionable advice. Things like politeness, small talk, respect for other's etc.
At the same time know when to be honest. I've seen the best communicators tell management exactly what management wants to hear over and over and projects kept being behind or over budget because there was a dysfunctional connection between the manager and the engineer who kept B.S.ing them with what they wanted to hear and the nitwit manager eating it up and for some reason never learning.
Systems reasoning, learn to understand the system from the line of code up through the stacks to the whole. Sounds cliche and it is but it will make you a better programmer.
Debugging. This will be most of your life. The more you understand the system, the better you are at it.
Managing upwards. Keep your manager happy and communicate your work to them.
Git and version control, learn them as in depth as you have time for. Every decent dev environment has these and the amount of people lacking this basic knowledge is staggering.
Bash/Linux or powershell/windows same thing. You can get an amazing amount of things done with shell scripting in your OS. Unless you have an insane amount of time I would pick one and learn in depth. These are rich systems.
A dynamic programming language in depth. There are so many concepts that will transfer between languages that if you know one in depth, you'll be able to pick another one up pretty fast as it's just semantics at that point.
SQL, this is an essential part of dev life and you will understand ORMs and data management better.
The personal skills:
Communication obviously. This is such a vague term and I think is abused as people just say 'lERn to CoMmUNicate' with no actionable advice. Things like politeness, small talk, respect for other's etc.
At the same time know when to be honest. I've seen the best communicators tell management exactly what management wants to hear over and over and projects kept being behind or over budget because there was a dysfunctional connection between the manager and the engineer who kept B.S.ing them with what they wanted to hear and the nitwit manager eating it up and for some reason never learning.
Systems reasoning, learn to understand the system from the line of code up through the stacks to the whole. Sounds cliche and it is but it will make you a better programmer.
Debugging. This will be most of your life. The more you understand the system, the better you are at it.
Managing upwards. Keep your manager happy and communicate your work to them.
Just my 2cents, alot of people mentioned alot criteria which I heard during my days as (empathy : backend engineer, abstract thinking : android dev, communication: company tech lead). But I think the core is the mindset to self improve that's best for you right NOW (self discipline).
This is really really really hard to do, since we are mostly lazy beings who rather click 50 arrow up key to find the one important command than remembering it or just dont mind to repeat a mundane process without finding a shortcut to do it faster. Programmers who I met that manage to finish a task in 10 minutes instead of 1 day usually have this trait. But I guess this applies to other jobs as well ¯\_(ツ)_/¯
Btw, I used to work as a part timer at my university department. One day one of the staff ask me to reformat about 90 Excels document to her desire format, she spend 10 minutes showing me how to type them out one by one. After this, I went to setup Python environment in that computer and google how to read excel docs. In a few hours I have finish the work that what would took me more than half a day to finish.
This is really really really hard to do, since we are mostly lazy beings who rather click 50 arrow up key to find the one important command than remembering it or just dont mind to repeat a mundane process without finding a shortcut to do it faster. Programmers who I met that manage to finish a task in 10 minutes instead of 1 day usually have this trait. But I guess this applies to other jobs as well ¯\_(ツ)_/¯
Btw, I used to work as a part timer at my university department. One day one of the staff ask me to reformat about 90 Excels document to her desire format, she spend 10 minutes showing me how to type them out one by one. After this, I went to setup Python environment in that computer and google how to read excel docs. In a few hours I have finish the work that what would took me more than half a day to finish.
The essential skill needed to be an <anything> is to be interested in it and enjoy it. Paul Graham writes (somewhere in his essays, couldn't find it with a quick scan) that the notion of 'aptitude' is highly suspicious. We get better at things by doing them, and after doing them for a long time we look like we have an aptitude.
A caveat: Just as being interested in and liking to play a sport won't get you to play at the top levels without talent as well, there are lots of programmer's jobs that will be out of reach, but others WILL be in reach.
A caveat: Just as being interested in and liking to play a sport won't get you to play at the top levels without talent as well, there are lots of programmer's jobs that will be out of reach, but others WILL be in reach.
My usual answer to what it takes to be a career programmer is 'you need to be able to sit down and concentrate on a problem for most of the day.'
If you can do that, the rest of the techniques can be learned with time and effort.
If you can do that, the rest of the techniques can be learned with time and effort.
The question is too broad, but along the lines of Norvig's answer...
There's a particular micro-expression I sometimes notice with people who are working on a software problem. I notice it when something goes wrong unexpectedly.
People who aren't particularly talented at SW development, for a brief instant, give a facial expression of disgust when something crashes or behaves incorrectly. People who are awesome at development, instead, have a look of amusement like they're actually looking forward to see what happened. These facial "micro-expressions" are really fast and subtle, you really have pay attention and it doesn't always work but I've seen it enough times to believe it shows something.
I think this goes back to the impulse to "improve" things that Norvig mentions. You really have to enjoy the act of programming, to be willing to improve on it. It's a kind of feedback loop. Just MHO.
There's a particular micro-expression I sometimes notice with people who are working on a software problem. I notice it when something goes wrong unexpectedly.
People who aren't particularly talented at SW development, for a brief instant, give a facial expression of disgust when something crashes or behaves incorrectly. People who are awesome at development, instead, have a look of amusement like they're actually looking forward to see what happened. These facial "micro-expressions" are really fast and subtle, you really have pay attention and it doesn't always work but I've seen it enough times to believe it shows something.
I think this goes back to the impulse to "improve" things that Norvig mentions. You really have to enjoy the act of programming, to be willing to improve on it. It's a kind of feedback loop. Just MHO.
A pro will additionally want to delay fixing a problem so that the root cause can be determined if there is no major financial cost. Management will want to brute force solve the problem right away and forget about it. Usually this involves restarting something: machine/instance.
It's a lot easier to be interested in a surprise failure mode when you're not under the gun to deliver on a deadline.
I find failures interesting too, but I'm not feeling happy when I expect the reason will be because the tooling I'm using hides information behind insufficient logging or the answer I seek is probably on a system I don't have permission to access.
I find failures interesting too, but I'm not feeling happy when I expect the reason will be because the tooling I'm using hides information behind insufficient logging or the answer I seek is probably on a system I don't have permission to access.
There's also another side of disgust that motivates you to improve things. Some of my favorite work were born out of sheer anger
I agree, a bug can lead to excitement. A bug somewhere deep in a framework that is now causing issues on production, no amusement to be found.
The thing about micro-expressions is that they're involuntary. You can't hide them unless you're specifically aiming to do that. Your face might very well betray a few hundred milliseconds of amusement immediately before you shout a swear-word.
Nah... I constantly say ah... fuck this shit! I then proceed to fix the bitch of whatever problem it is. I'm a real programmer though.
Know when to seek out assistance from others. I would much rather spend 30 minutes in cooperation with others than multiple hours by my self.
Work smart, not hard.
Work smart, not hard.
In addition to tolerance of frustration and tenacity (as has been mentioned several times here already), I'll go with being good at the old Sesame Street game "One of these things is not like the other, One of these things is not the same" - I feel like I'm playing that game a lot when I'm debugging.
Teamwork
Grit. Don't give up on hard problems. Manage your feelings. Overcome obstacles. Practice patience.
Been programming for 40 years. This is the best answer here, and why I came to comment.
If you're not making headway, step back, sleep on it, and try another approach. Giving up will guarantee you fail. You haven't failed until you give up.
Also related, fail fast; do the minimum amount of work to create a proof-of-concept, to see if you're on the right track or not. Don't build the whole UI until the algorithm is working, don't focus on the wrong things, focus on the most important thing first.
And finally, know when to ask for help. There is no shame in it. It's better to ask for help than waste time.
Just. Never. Give. Up.
If you're not making headway, step back, sleep on it, and try another approach. Giving up will guarantee you fail. You haven't failed until you give up.
Also related, fail fast; do the minimum amount of work to create a proof-of-concept, to see if you're on the right track or not. Don't build the whole UI until the algorithm is working, don't focus on the wrong things, focus on the most important thing first.
And finally, know when to ask for help. There is no shame in it. It's better to ask for help than waste time.
Just. Never. Give. Up.
Thank you for your kind comment
First of all, a programmer turns a spec into working code. That's the easy part. Engineering is gathering requirements, designing the spec and ultimately coding it.
To be an engineer one must love to learn, learn fast and be able to learn on his own. It's not a job where you can expect to get training, it's a profession where you must be able to do some of the growing by yourself. It's a constant stream of new tech and new business domain knowledge. Here reading skills are absolutely required: a lot of questions can simply be answered by the relevant man page or by finding a reliable source for whatever knowledge is required for the task. You'll effectively have to become a domain expert several times in a career.
Systematic thinking and pattern recognition are essential skills to have. Our industry creates buzzwords every month and new fads in programming languages and frameworks but most core concepts remain unchanged since their inception.
Logic is absolutely required, and the ability to use the scientific method. This is crucial when debugging where you'll have to observe a problem, collect data on state, formulate an hypothesis on what caused the invalid state and verify your hypothesis. There's no "big picture" here, and every detail matters when doing this so in practice an engineers will often have to be able to keep the whole state of the system in his mind and step through it.
Communication skills are great to have; they effectively allow you to delegate and help colleagues onboard to whatever you are working on faster. From an outside point of view it's effectively super-powers, and if you want to play the politics game, allows you to get the best engineers to want to work with you.
To be an engineer one must love to learn, learn fast and be able to learn on his own. It's not a job where you can expect to get training, it's a profession where you must be able to do some of the growing by yourself. It's a constant stream of new tech and new business domain knowledge. Here reading skills are absolutely required: a lot of questions can simply be answered by the relevant man page or by finding a reliable source for whatever knowledge is required for the task. You'll effectively have to become a domain expert several times in a career.
Systematic thinking and pattern recognition are essential skills to have. Our industry creates buzzwords every month and new fads in programming languages and frameworks but most core concepts remain unchanged since their inception.
Logic is absolutely required, and the ability to use the scientific method. This is crucial when debugging where you'll have to observe a problem, collect data on state, formulate an hypothesis on what caused the invalid state and verify your hypothesis. There's no "big picture" here, and every detail matters when doing this so in practice an engineers will often have to be able to keep the whole state of the system in his mind and step through it.
Communication skills are great to have; they effectively allow you to delegate and help colleagues onboard to whatever you are working on faster. From an outside point of view it's effectively super-powers, and if you want to play the politics game, allows you to get the best engineers to want to work with you.
You need to believe that computers are understandable. There’s no magic involved. Eventually, every abstraction leaks — so if you have fear or learned helplessness blocking you from trying to understand the leaky abstraction layer, the only way you can debug it is by squeezing your eyes shut and trying random things, which is ineffective. You really need to internalize that even things that seem mysterious happen for reasons, and that those reasons are something you could in principle figure out.
As an extension of this, you need the ability to resist the urge to flip a table and walk away from a problem that seems too hard.
Debugging can be like picking threads out of a tangle of yarn most of the time. Often when you have the most riding on the line.
Stress management/Self-management skills are critical (should be in the top 3) and often overlooked.
Debugging can be like picking threads out of a tangle of yarn most of the time. Often when you have the most riding on the line.
Stress management/Self-management skills are critical (should be in the top 3) and often overlooked.
Frustration tolerance! Don't get me wrong, programming is frequently joyful, but sometimes you'll run into bugs that are maddening and require a lot of divide and conquer sort of work, and being able to separate yourself from the natural frustration is key to making progress.
[deleted]
Here's one I find doesn't get enough credit: Reading comprehension.
That can be interpreted as reading someone else's code, but even more importantly: Just being able to understand plain English (or whatever human language).
I've seen so much code that used an API incorrectly, or misunderstood (or simply ignored) documentation. Being able to RTFM, imo, is essential. See also: Understanding what your boss wants and delivering it.
That can be interpreted as reading someone else's code, but even more importantly: Just being able to understand plain English (or whatever human language).
I've seen so much code that used an API incorrectly, or misunderstood (or simply ignored) documentation. Being able to RTFM, imo, is essential. See also: Understanding what your boss wants and delivering it.
You need a few skills to be a good programmer:
1) Literacy. You have to know how to read (and ideally write in) your native language at a relatively high level. So much of our craft's knowledge is written down, in technical if not arcane terms, that in order to learn you really have to read.
2) The ability to reason about causes and effects, that is, to envision in your head what the computer will do when it evaluates a statement in your program. Also, the ability to back-reason which statements will produce a desired effect. You need to be able to predict what will happen before you write the code and test it out after the code is written. You'd be surprised how few people have this ability developed and how hard programming is for the general population as a consequence.
3) The ability to be humble and stay focused. Your program will take much longer to write than you think it will, and there will be more bugs. You have to have the diligence and passion to see it through.
1) Literacy. You have to know how to read (and ideally write in) your native language at a relatively high level. So much of our craft's knowledge is written down, in technical if not arcane terms, that in order to learn you really have to read.
2) The ability to reason about causes and effects, that is, to envision in your head what the computer will do when it evaluates a statement in your program. Also, the ability to back-reason which statements will produce a desired effect. You need to be able to predict what will happen before you write the code and test it out after the code is written. You'd be surprised how few people have this ability developed and how hard programming is for the general population as a consequence.
3) The ability to be humble and stay focused. Your program will take much longer to write than you think it will, and there will be more bugs. You have to have the diligence and passion to see it through.
The best way I could summarize it is that coding is the easiest part of my job (unless I have to touch CSS). Working with people is by far the hardest part.
I like the differentiation that engineering is programming integrated over time. [1]
To be a programmer you need the direct hard skills of coding literacy, analytical and logical thinking, combined with enough grit and creativity to see a problem through to completion. If you have that, you'll be a decent programmer, but you may not be a good engineer.
Engineering requires the maturity of thought to consider your actions and your solution over time. It requires more wholistic thinking and not just from the tech architecture point of view. Human soft skills tend to be more important over these time scales: communication, empathy, humility, courage. It's these skills that sustain success.
[1] https://www.oreilly.com/library/view/software-engineering-at...
To be a programmer you need the direct hard skills of coding literacy, analytical and logical thinking, combined with enough grit and creativity to see a problem through to completion. If you have that, you'll be a decent programmer, but you may not be a good engineer.
Engineering requires the maturity of thought to consider your actions and your solution over time. It requires more wholistic thinking and not just from the tech architecture point of view. Human soft skills tend to be more important over these time scales: communication, empathy, humility, courage. It's these skills that sustain success.
[1] https://www.oreilly.com/library/view/software-engineering-at...
You have to like it. Or you'll never be worth anything at it.
"Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve." -- Alan Perlis
"Don’t only practice your art, but force your way into its secrets, for it and knowledge can raise men to the divine."
- Ludvig van Beethoven
I would say it comes down to a character attribute, and a simple skill. The attribute is curiosity - why does something do what it does, and the simple skill is how to google. That's it. I've seen the most traditionally under-qualified people become excellent, simply by always asking why, and trying to find a answer.
I would say it comes down to a character attribute, and a simple skill. The attribute is curiosity - why does something do what it does, and the simple skill is how to google. That's it. I've seen the most traditionally under-qualified people become excellent, simply by always asking why, and trying to find a answer.
A capacity to endure endless mind-numbing boredom.
If learning new things and solving problems is boring to you, then programming is the wrong job for you.
TBF I spend more time painstakingly following stack traces around to figure out the root cause of some weird bug than I do learning cool technologies or devising novel algorithms. It's all "fun" or "interesting" in a certain (sometimes masochistic) sort-of way, but it definitely requires a certain mental fortitude. Even learning the coolest of new tech requires hours of slogging through documentation or dealing with development environment headaches.
Listening
1. Communication Skills - Clearly understanding what others are saying and expressing one's opinion in a polite, and respectful manner is a skill one must master. Most of the time it's better to listen first rather than talking first.
2. Prioritization - Learn to prioritize and sometimes to say "NO" to people.
3. Delegation - One cannot do everything by oneself. Learn to delegate and get help from others.
4. Whenever you do some task, always question why am I doing this, why this needs to be done in a certain manner and learn all the background(domain specific) knowledge related to the task.
5. Learn how to debug - I cannot stress enough how important this is. Most of the time you would spend maintaining, coding, and changing, legacy/existing code written by someone else. If you do not know how to debug and follow the trail like Enola Holmes, you'd always have to depend on the help of others which is very inconvenient for you as well as for others.
Apart from that as mentioned in the other answers it's always good to be a smart cookie, but it's not essential.
2. Prioritization - Learn to prioritize and sometimes to say "NO" to people.
3. Delegation - One cannot do everything by oneself. Learn to delegate and get help from others.
4. Whenever you do some task, always question why am I doing this, why this needs to be done in a certain manner and learn all the background(domain specific) knowledge related to the task.
5. Learn how to debug - I cannot stress enough how important this is. Most of the time you would spend maintaining, coding, and changing, legacy/existing code written by someone else. If you do not know how to debug and follow the trail like Enola Holmes, you'd always have to depend on the help of others which is very inconvenient for you as well as for others.
Apart from that as mentioned in the other answers it's always good to be a smart cookie, but it's not essential.
Being able to read other people’s code.
To be able to write code, you must first be able to read code. This means you must be able to 'simulate' what the computer is doing when it executes a program — or at least the bit of it you're working on — in your own head before you can write it. Tools can and do help with this, but they cannot think for you.
Competence in engineering and architecture come from expanding the capabilities of your mind to simulate more complex programs and to think in abstractions.
Competence in engineering and architecture come from expanding the capabilities of your mind to simulate more complex programs and to think in abstractions.
learn to read and follow instructions. after all programming is all about writing them
[deleted]
You have to be comfortable enough with computers (real computers with keyboards) to be open to using one 8 hours a day. It may sound obvious but it's not obvious to a lot of people especially with the way programming is marketed to young people through board games, tablets, etc.
The ability to stay with a problem for a long time. I think some folks will see something they don't understand and just disengage with it, but a lot of successful programmers that I've seen will continue to think about situations/ problems a lot longer after realizing they haven't fully grokked it, until eventually they do.
I'd second this. The most important skill for a programmer is being able to look at a problem and say "I have absolutely no idea what's going on here, but I know that I eventually will". Going from a complete lack of context on something to fully comprehending and solving it is infinitely satisfying.
Second this - I think part of being a programmer is having a really hard head that stands up to being banged against that wall, over and over, until the thing you're trying to make work works:)
As a result of a few recent Forth threads here, I first heard of STOIC on September 29th. (1 Week ago) Intrigued at the novel way it addressed the shortcomings of Forth which limited its use... I tracked down STOICAL. It really got me motivated, and I decided to download it and dive in.
At that moment, I had almost zero of the specific bits of knowledge required to make it work. I only used Linux sporadically. I never programmed in Linux. I actively avoided C for the last 40 years. Yet, I dug in.
Last night I got it compiled enough that it now starts up, and then hangs. This is a vast improvement from 2 days ago. I now have WSL installed, with gcc, automake, and all manner of stuff required to make it go. I still use Notepad++ and windows to edit the source (as the /home/mike folder is visible as a network share) I've even got git/github going.
I know I'll get it up and running in short order. Then I'll start banging away at it until it matches my ideas of how it should work. My goal is to produce a Forth-ish compiler that doesn't get people intrigued but then run out of steam.
STOIC checks all the boxes, it's Imperative, Structured, Object Oriented, Functional, Concatenative and HomoIconic.
And right now.... it doesn't even boot... but it will! That's programming!
At that moment, I had almost zero of the specific bits of knowledge required to make it work. I only used Linux sporadically. I never programmed in Linux. I actively avoided C for the last 40 years. Yet, I dug in.
Last night I got it compiled enough that it now starts up, and then hangs. This is a vast improvement from 2 days ago. I now have WSL installed, with gcc, automake, and all manner of stuff required to make it go. I still use Notepad++ and windows to edit the source (as the /home/mike folder is visible as a network share) I've even got git/github going.
I know I'll get it up and running in short order. Then I'll start banging away at it until it matches my ideas of how it should work. My goal is to produce a Forth-ish compiler that doesn't get people intrigued but then run out of steam.
STOIC checks all the boxes, it's Imperative, Structured, Object Oriented, Functional, Concatenative and HomoIconic.
And right now.... it doesn't even boot... but it will! That's programming!
A lot of great comments here and I generally agree. One thing I think we all need to consider essential is ethics. As software continues to eat the world, programmers are being used for unethical endeavors and I think all too often we don't notice it.
I'm not suggesting every programmer who works for the likes of Facebook, Exxon, and Comcast quit their jobs. (though, if they did, wouldn't that turn some influential heads in the right direction?) Simply push back when asked to work on something that you feel might cause harm.
I'm not suggesting every programmer who works for the likes of Facebook, Exxon, and Comcast quit their jobs. (though, if they did, wouldn't that turn some influential heads in the right direction?) Simply push back when asked to work on something that you feel might cause harm.
Agreed. Another way to put it: 1) Honesty. 2) Treating others the way oneself would want to be treated (the Golden Rule)--from this one can derive testing, the right amount of documenation, observing, communicating, working well with others, so much.
And 3) the ability to think something through patiently, thinking of what should happen, and what could go wrong, and being willing to develop the skills to make a ~"plan" (i.e., a program) that will do it properly.
And 3) the ability to think something through patiently, thinking of what should happen, and what could go wrong, and being willing to develop the skills to make a ~"plan" (i.e., a program) that will do it properly.
If you intend to work on a team larger than, say, 4 people, writing english (or your team's common language that isn't english) is supremely important.
I spend a lot of time reading the writing of other programmers. I've read 4 page documents that are a slog and 20 page documents that are a joy. Your writing, in a lot of cases, will be people's first impression of you, NOT your code.
I spend a lot of time reading the writing of other programmers. I've read 4 page documents that are a slog and 20 page documents that are a joy. Your writing, in a lot of cases, will be people's first impression of you, NOT your code.
This is an incredible thread. Thank you all for sharing.
For me, a good programmer realizes that "everything is code". Like, sometimes it's easy to think X problem is too hard for me or I don't have enough experience or this bug is unfixable but end of the day, it's all just code. You can change it however you want and if someone else did implemented something before, it's highly likely that you'll be able to do the same. Having a level of distance from the code one writes really helps.
For me, a good programmer realizes that "everything is code". Like, sometimes it's easy to think X problem is too hard for me or I don't have enough experience or this bug is unfixable but end of the day, it's all just code. You can change it however you want and if someone else did implemented something before, it's highly likely that you'll be able to do the same. Having a level of distance from the code one writes really helps.
negotiating top compensation and demanding respect for your work, and learning to say no.
a thirst for new knowledge and the ability to communicate that knowledge to others in a way they understand. Speaking to a fellow programmer is different than speaking to a manager is different than speaking to a customer.
also, knowing how to say "no" professionally and firmly is an important and respected skill.
finally, being able to see the forest through the trees and value the business side of what you're doing is a key perspective. Everyone loves to trash talk Sales/Marketing/Management but those people turn your programming into your paycheck so a little understanding is deserved.
also, knowing how to say "no" professionally and firmly is an important and respected skill.
finally, being able to see the forest through the trees and value the business side of what you're doing is a key perspective. Everyone loves to trash talk Sales/Marketing/Management but those people turn your programming into your paycheck so a little understanding is deserved.
Dogged persistence. Keep trying, don't be intellectually lazy. Ask someone else only once you've had numerous tries at solving a problem yourself. That, and a logical mind.
Boolean algebra
I’ve been studying beginner programmers recently on forums plus I’ve done some mentoring. This is market research if you like.
What resonates with me is the sheer persistence of these learners in the face of the rediculous complexity.
I learned basic at < 10 yo but there wasn’t much to it i the 80s on a home computer. No browsers. No closures. No NPM. No errors because “Yer on Windows”.
You have people doing freecodecamp pushing arch other along, many self taught getting complex apps working with React. Starting from no experience.
So yes keep on going when you hit a wall, struggle through it, and the next thing, and same shit for the job interviews.
Persistence and a love of learning are essential and it’s horrible working with coders that don’t have this trait.
Also:
* team work
* emotional intelligence
* testing and quality
* understanding the business impact
* humility - it’s a skill!
* estimation
* pushing back
* job interview skills
* career strategy (I suck at!)
* going wide and learning lots of things
* going deep in some things
* communication
* inquisitiveness
* getting things done / staving off perfectionism
* some ui/ux awareness
* cloud architecture basics or sys admin basics
* and that’s not all! Etc. etc.
All of which you’ll definitely learn on the job so no need to stress :-)
What resonates with me is the sheer persistence of these learners in the face of the rediculous complexity.
I learned basic at < 10 yo but there wasn’t much to it i the 80s on a home computer. No browsers. No closures. No NPM. No errors because “Yer on Windows”.
You have people doing freecodecamp pushing arch other along, many self taught getting complex apps working with React. Starting from no experience.
So yes keep on going when you hit a wall, struggle through it, and the next thing, and same shit for the job interviews.
Persistence and a love of learning are essential and it’s horrible working with coders that don’t have this trait.
Also:
* team work
* emotional intelligence
* testing and quality
* understanding the business impact
* humility - it’s a skill!
* estimation
* pushing back
* job interview skills
* career strategy (I suck at!)
* going wide and learning lots of things
* going deep in some things
* communication
* inquisitiveness
* getting things done / staving off perfectionism
* some ui/ux awareness
* cloud architecture basics or sys admin basics
* and that’s not all! Etc. etc.
All of which you’ll definitely learn on the job so no need to stress :-)
Abstraction.
1) Curiosity
2) Aptitude
2) Aptitude
#1 skill programmers are paid for is converting requirements (wants, ideas) from human to deterministic reproducable algorithms.
I think this is exactly why "communication" crops up so often and why "talk to your customers" is the number one advice for founders.
I think it's a really underrated / underinvested skill in the industry (from my experience) with a lot of complexity. For example, there's so many levels of listening. It's one thing to understand what someone is saying but yet another to pick up on meta messages (facial expression / body language) that signal true thoughts / feelings.
I think it's a really underrated / underinvested skill in the industry (from my experience) with a lot of complexity. For example, there's so many levels of listening. It's one thing to understand what someone is saying but yet another to pick up on meta messages (facial expression / body language) that signal true thoughts / feelings.
Yes.
I whould say “understanding” part of communication crucial for programmer.
But always together with “converting what is understood in formalized logic”
I whould say “understanding” part of communication crucial for programmer.
But always together with “converting what is understood in formalized logic”
While many smart people here I believe said the most important things, I would like to add:
Do not accept "magical" behaviour.
I came across quite some projects which had Cypress E2E tests which were, according to the developers, "unstable".
So what is the magic part which makes it fail? There is no such thing as an instable test as such in a test environment, in this case it was a broken test with unmocked data which occasionally threw errors, depending on the OS and speed of the machine it was running on.
In another scenario the was a random number involved, which randomly chose a picture in the test development and depending wether it needed cropping or not, an additional popup would open.
I was told: "well, sometimes it works, sometimes it doesn't". Nobody actually investigated further, tests were excluded instead. Noone ever looked at the artifacts/screenshots/logs.
Always investigate, there is a reason for every "magical" behaviour.
Do not accept "magical" behaviour.
I came across quite some projects which had Cypress E2E tests which were, according to the developers, "unstable".
So what is the magic part which makes it fail? There is no such thing as an instable test as such in a test environment, in this case it was a broken test with unmocked data which occasionally threw errors, depending on the OS and speed of the machine it was running on.
In another scenario the was a random number involved, which randomly chose a picture in the test development and depending wether it needed cropping or not, an additional popup would open.
I was told: "well, sometimes it works, sometimes it doesn't". Nobody actually investigated further, tests were excluded instead. Noone ever looked at the artifacts/screenshots/logs.
Always investigate, there is a reason for every "magical" behaviour.
Imagination, to come up with solutions!
Look up things you don't know before you become frustrated that you don't know them.
The ability to drink coffee
I consider curiosity and perseverance to be the most important characteristics for any career.
The ability to understand and effectively seek clarity on the specifics of the problem you’re solving (both “what does the prospective user actually want?” and “what makes this problem and/or solution distinct from seemingly similar problems and/or solutions?”), and the corresponding ability to map that understanding and clarity to the selection and appropriate application of generalized tools that will achieve those specifics.
In other words:
- Empathy
- Listening
- Communicating
- Collaborating
- Abstract thinking
In other words:
- Empathy
- Listening
- Communicating
- Collaborating
- Abstract thinking
Not mine, I read it somewhere: "A good programmer is one who looks both sides when crossing a one-way street".
Insatiable curiosity. Period.
Insatiable curiosity.
"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?