Live data from Hacker News

Ask HN: Essential skill needed to be a programmer?

news.ycombinator.com

71–80 of 193 posts

Re: Ask HN: Essential skill needed to be a programmer?

#71
post #21

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

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.

Re: Ask HN: Essential skill needed to be a programmer?

#72
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.

Re: Ask HN: Essential skill needed to be a programmer?

#75
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.

Re: Ask HN: Essential skill needed to be a programmer?

#79
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.

Re: Ask HN: Essential skill needed to be a programmer?

#80
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.

Post reply on HN