* Recursive file system management tools. Most developers cannot navigate a tree model and cower in great fear
* performance analysis/monitoring tools. Most developers are astoundingly bad at performance and then lie about it with weird unfounded guesses
* markdown to html parser or the opposite. Most developers have no idea the actual cost of involvement required for basic string parsing and wrongly believe it’s free
* network proxy. Aside from authentication this is mind blowingly simple. Most developers will supremely over engineer this
* API documentation. In a world where the average developer struggles to write an email actually describing inputs, purpose, and outputs clear enough for a stranger to follow can be quite the impossibility
I got a job ... true devops culture ... where I use Splunk etc. as much as I use git, I finally grok P99 and aggegrations and I don't hate it. It has been a mind opener and it is great to be data driven.
As an aside I think where I have seen bad performance it has been mostly architectural choices over O(N) stuff. These take a lot of organizational will power to fix properly as it costs money, time and egos.
When I interviewed at Facebook they asked me about O(N) performance of something. It felt like I was talking to a small child pretending to be smart. Don’t guess. If they aren’t willing to measure two things then compare those numbers performance is completely irrelevant. When that is impossible to understand it’s time to abandon the conversation and walk away.
Core problem solving skills. Debugging, triaging, fault-finding.
The thing that makes me a good programmer is my ability to consume a bunch of code, model the program in my head, and analyze likely faulting paths. The code is secondary. Your job as a programmer is to solve problems. Code is just the tool we use to implement the solution.
Instead of bashing your head into the keyboard until the bug goes away, take your time to actually understand the bug. Make an effort to grok as much of the program as you can. Draw flow charts and diagrams if you can't keep the model in your head.
A related point: understand what the machine is doing and how your code interacts with it. If you're aware of the physicality of the machine, you'll tend towards better and more optimal code.
Really you want to learn programming, and not code. Tinker with as many different languages as you can, but don't overly concern youself with advanced features. Learn how to walk into a codebase in an unfamiliar language and immediately start hacking. You'll eventually learn to see the program behind the code. To a good programmer, code is code is code, no matter the language. Really think deeply about the distinction between a program and the code. Again, code is just the tool we use to create a program.
Other than that, the single most useful thing you can learn is shell scripting. It cannot be overstated how important and useful bash and powershell scripts are. They are everywhere and most programmers have written countless shell scripts.
To sum up: learn the theory and philosophy of programming and computing. You have to build a deep understanding of programming in the abstract before you can apply code. You want to cultivate a talent for programming. Skills come after that, and you pick them up along the way. We are all constantly learning new skills, it's part of the job.
A painter does not master the art by studying brushes. A master understands art, composition, colors and can apply that understanding with a brush, pencil, pastel or any other tool. She does, of course, specialize in and deeply understands a small subset of those tools, but she can still produce masterworks with unfamiliar tools.
Learn when to pushback and when to give in. Pushing back makes you looks smarter giving in more of a team player. Figuring out a proper balance for your environment is key.
Learn to constantly explore and be curious. Think like a hacker and the skills you need will become apparent when you try to do something and hit a wall.
Read this once a day for 7 days. You already are a better programmer.
A lot of emphasis is put on programming "the code". What I find can simplify a lot of thought processes is to think of the overall action from the outside of the code. Often a system is transitioning from one persisted, consistent state to another persisted consistent state. Reasoning should begin from what needs to be applied to the persisted state at the lower level (e.g. SQL statements). The 'consistency' can be thought of in terms of invariants which must be upheld. Once you have those in mind, you only have to work out the 'plumbing' details of how the code is structured to get the job done.
Besides that learn the details about your infrastructure (what it can and can't do, datastores, networking) and your frameworks/libraries. Don't be afraid to go outside the frequently painted lines to do what's possible, not only what's been done before.
In terms of programming, it's good to learn other languages and formulations that let you think at a higher level. e.g. using map or reduce level processing or single assignment of variable values, immutable collections once constructed, etc simplifies code construction while avoiding common pitfalls like off-by-one errors, shared mutable references, or distributing a single piece of logic in different places. Pay a lot of attention to how to name things, lower level constructs should simply be what they do, higher level things go toward why they're being done. Separation of mechanism (lower implementation) and policy (higher level uses) fits naturally into structuring which is easy to work with and highly adaptable to new requirements.
Lastly don't refactor dogmatically. Choose what the factors are before redrawing the system/process along those seams. Deal with each factor once and avoid having to write, reason about, test factors in combination whenever possible.
I wouldn't consider any of these things as 'hard' (unless you meant technical), it only seems so because they are considered later (after being painted into a corner) rather than sooner.
Probably being pedantic, but I disagree on the order. What I understand is that "giving it no thoughts" is less bad than "doing it prematurely".
The worse is to not give it a thought IMO (usually people justify that by saying "premature optimization is the root of all evil", where actually they just couldn't be bothered to think). Writing bad code and justifying it by "I'm optimizing" is also pretty bad.
Attention to soft skills involving people might be a hard skill for you. Or not. The question does not contain sufficient context. But often people want to improve in areas that avoid dealing with areas they want to avoid.
Hard skills can be outsourced (Facebook hired Carmac, Google hired Norvig). Soft skills can't. Soft skills are what usually makes someone a good-programmer-in-the-sense-people-want-to-work-with-them-again. Good luck.
Some of the other skills mentioned are on the softer side but still good but touch typing is a specific, practicable hard skill that does help. You can be a decent programmer without knowing how to touch type, and so much of programming is reading, not writing, but when you are going from thought to code, being able to do so at 120 wpm vs 20 wpm makes a difference.
* Recursive file system management tools. Most developers cannot navigate a tree model and cower in great fear
* performance analysis/monitoring tools. Most developers are astoundingly bad at performance and then lie about it with weird unfounded guesses
* markdown to html parser or the opposite. Most developers have no idea the actual cost of involvement required for basic string parsing and wrongly believe it’s free
* network proxy. Aside from authentication this is mind blowingly simple. Most developers will supremely over engineer this
* API documentation. In a world where the average developer struggles to write an email actually describing inputs, purpose, and outputs clear enough for a stranger to follow can be quite the impossibility
---
That is taken from a recent comment in this thread: https://news.ycombinator.com/item?id=42157595
I got a job ... true devops culture ... where I use Splunk etc. as much as I use git, I finally grok P99 and aggegrations and I don't hate it. It has been a mind opener and it is great to be data driven.
As an aside I think where I have seen bad performance it has been mostly architectural choices over O(N) stuff. These take a lot of organizational will power to fix properly as it costs money, time and egos.
When I interviewed at Facebook they asked me about O(N) performance of something. It felt like I was talking to a small child pretending to be smart. Don’t guess. If they aren’t willing to measure two things then compare those numbers performance is completely irrelevant. When that is impossible to understand it’s time to abandon the conversation and walk away.
Core problem solving skills. Debugging, triaging, fault-finding.
The thing that makes me a good programmer is my ability to consume a bunch of code, model the program in my head, and analyze likely faulting paths. The code is secondary. Your job as a programmer is to solve problems. Code is just the tool we use to implement the solution.
Instead of bashing your head into the keyboard until the bug goes away, take your time to actually understand the bug. Make an effort to grok as much of the program as you can. Draw flow charts and diagrams if you can't keep the model in your head.
A related point: understand what the machine is doing and how your code interacts with it. If you're aware of the physicality of the machine, you'll tend towards better and more optimal code.
Really you want to learn programming, and not code. Tinker with as many different languages as you can, but don't overly concern youself with advanced features. Learn how to walk into a codebase in an unfamiliar language and immediately start hacking. You'll eventually learn to see the program behind the code. To a good programmer, code is code is code, no matter the language. Really think deeply about the distinction between a program and the code. Again, code is just the tool we use to create a program.
Other than that, the single most useful thing you can learn is shell scripting. It cannot be overstated how important and useful bash and powershell scripts are. They are everywhere and most programmers have written countless shell scripts.
To sum up: learn the theory and philosophy of programming and computing. You have to build a deep understanding of programming in the abstract before you can apply code. You want to cultivate a talent for programming. Skills come after that, and you pick them up along the way. We are all constantly learning new skills, it's part of the job.
A painter does not master the art by studying brushes. A master understands art, composition, colors and can apply that understanding with a brush, pencil, pastel or any other tool. She does, of course, specialize in and deeply understands a small subset of those tools, but she can still produce masterworks with unfamiliar tools.
Learn the art, not the tool.
You haven't mentioned which hard skills you've already mastered.
* Abstract reasoning - everything in programming is abstraction
* Critical thinking - is the first way you've thought of to solve something actually an optimal way? how could you improve it?
* Problem decomposition - solve large problems by breaking them down into smaller component problems
* Multiprocessing/multithreading and IPC - at some point one process/thread isn't enough
* Networking fundamentals - may not contribute directly to better programming per se but will for sure help with debugging/troubleshooting
Learn when to pushback and when to give in. Pushing back makes you looks smarter giving in more of a team player. Figuring out a proper balance for your environment is key.
Learn to constantly explore and be curious. Think like a hacker and the skills you need will become apparent when you try to do something and hit a wall.
Read this once a day for 7 days. You already are a better programmer.
https://www.mit.edu/~xela/tao.html
A lot of emphasis is put on programming "the code". What I find can simplify a lot of thought processes is to think of the overall action from the outside of the code. Often a system is transitioning from one persisted, consistent state to another persisted consistent state. Reasoning should begin from what needs to be applied to the persisted state at the lower level (e.g. SQL statements). The 'consistency' can be thought of in terms of invariants which must be upheld. Once you have those in mind, you only have to work out the 'plumbing' details of how the code is structured to get the job done.
Besides that learn the details about your infrastructure (what it can and can't do, datastores, networking) and your frameworks/libraries. Don't be afraid to go outside the frequently painted lines to do what's possible, not only what's been done before.
In terms of programming, it's good to learn other languages and formulations that let you think at a higher level. e.g. using map or reduce level processing or single assignment of variable values, immutable collections once constructed, etc simplifies code construction while avoiding common pitfalls like off-by-one errors, shared mutable references, or distributing a single piece of logic in different places. Pay a lot of attention to how to name things, lower level constructs should simply be what they do, higher level things go toward why they're being done. Separation of mechanism (lower implementation) and policy (higher level uses) fits naturally into structuring which is easy to work with and highly adaptable to new requirements.
Lastly don't refactor dogmatically. Choose what the factors are before redrawing the system/process along those seams. Deal with each factor once and avoid having to write, reason about, test factors in combination whenever possible.
I wouldn't consider any of these things as 'hard' (unless you meant technical), it only seems so because they are considered later (after being painted into a corner) rather than sooner.
Optimization: not everyone has a super fast computer and a super fast internet connection. Too much is wasted there.
To do it prematurely is the biggest sin, to give no thought is the second, and to not be able to do profile code is fatal.
Probably being pedantic, but I disagree on the order. What I understand is that "giving it no thoughts" is less bad than "doing it prematurely".
The worse is to not give it a thought IMO (usually people justify that by saying "premature optimization is the root of all evil", where actually they just couldn't be bothered to think). Writing bad code and justifying it by "I'm optimizing" is also pretty bad.
Developers should have common sense, not dogma.
You should specify better for whom, imo, because it’s a social concept that depends on a setting. What’s better in one place is worse in the other.
How to sit down still and write lots of programs. How to sit down still and read lots of programs.
Attention to soft skills involving people might be a hard skill for you. Or not. The question does not contain sufficient context. But often people want to improve in areas that avoid dealing with areas they want to avoid.
Hard skills can be outsourced (Facebook hired Carmac, Google hired Norvig). Soft skills can't. Soft skills are what usually makes someone a good-programmer-in-the-sense-people-want-to-work-with-them-again. Good luck.
The single biggest problem in software engineering (larger-scale programming) is this: Brain-to-brain transfer of technical information is hard.
Learn to get better at technical documentation. Learn how to really understand it even if it's not written all that well. And learn to write it well.
Functional programming
Math
Systems thinking
Machining
Oil-painting
Some of the other skills mentioned are on the softer side but still good but touch typing is a specific, practicable hard skill that does help. You can be a decent programmer without knowing how to touch type, and so much of programming is reading, not writing, but when you are going from thought to code, being able to do so at 120 wpm vs 20 wpm makes a difference.