Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What does it take to be a good programmer?

qristin.wordpress.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: What does it take to be a good programmer?

#101

Post by glouwbug »

vbezhenar wrote: post #19

IMO good programmer writes code that: 1. Solves task. 2. Does that within a necessary performance constraints. 3. Uses commonly accepted approaches, libraries, style, does not reinvent things which are not necessary to reinvent. 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project. 5. Extendable for changes which are li…

Are we talking about industry programming? A good programmer knows how to get in and out, and retire early, and spend the rest of their days working on projects that fulfill their needs

Re: What does it take to be a good programmer?

#102

Post by ChrisMarshallNY »

GoblinSlayer wrote: post #100
ChrisMarshallNY wrote: post #3

> You need to be really smart and have a scientific mindset. Most importantly you need to love learning new things. I'm not so sure that these are required . I think they are more akin to "commonly found characteristics." Especially the "scientific mindset" part. I have a disciplined mindset, but I suspect most scientists would take issue with me, calling it a "scientific" mindset. In my experience, being a good prob…

Stubborn problem solving isn't always good. A problem can be solved in many ways, some of then can lie in the realm of program architecture or even product strategy. If your solution conflicts with them, it will be thought of as narrow sighted.

True. It’s also possible to go all “Captain Ahab” on a bug, and waste a huge amount of resources, trying to fix a minor problem, or refusing to use a perfectly acceptable workaround.

Re: What does it take to be a good programmer?

#103

Post by ncmncm »

The most important quality that distinguishes a good programmer from a mediocre one is a very strong preference for simplicity.

To be more precise, they need to be able to cope with complexity in their environment, but be driven to simplify systems that respond to that complexity. This is done by making things with simple parts that can be plugged together cleanly. Systems have to match in overall complexity their environment, but small, composable parts and careful buildup of layers can keep complexity manageable locally.

Once a system gets away, it is very hard to bring it back.

Re: What does it take to be a good programmer?

#104

Post by tabtab »

jacquesm wrote: post #27
vbezhenar wrote: post #19

IMO good programmer writes code that: 1. Solves task. 2. Does that within a necessary performance constraints. 3. Uses commonly accepted approaches, libraries, style, does not reinvent things which are not necessary to reinvent. 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project. 5. Extendable for changes which are li…

5 and 6 are super hard decisions. You never really know what your code will be used for in the future, especially not if you make libraries. I try really hard to do this and over the years I've found myself more than once caught out by something that I wished I had foreseen but did not and, conversely, I have spent a lot of time preparing code for changes which seemed to be likely to happen but that never did.

Knowledge of the domain and general experience with similar domains helps. My horse sense about what's likely to change has improved with time. As far as #6, you don't want to outright limit change because the future surprises, but use a YAGNI-ish view of unlikely changes to keep the system simpler. In other words, you don't make it hard to change, you just don't spend complexity on things unlikely to change. You only spend abstraction-related complexity on things likely to change.

Re: What does it take to be a good programmer?

#105

Post by dc-programmer »

GoblinSlayer wrote: post #99
dc-programmer wrote: post #78

Earlier quoted context omitted.

What you are saying absolutely makes sense to me for domains like device drivers. I think it becomes a lot more questionable when your coworker wants to write their own JSON parser or HTTP server for use on a commodity x86 linux box. It’s an incredible waste of resources and a major security hazard too boot.

I wrote JSON parser and http client for commodity platform, and they are 100 times safer than everything else, partly because they aren't overengineered beyond all reason.

I don’t doubt your abilities but I personally will always go with the choice that bounds the maximum risk to myself and the company every time

Re: What does it take to be a good programmer?

#106

Post by eternityforest »

HideousKojima wrote: post #44
eternityforest wrote: post #38

A good programmer: * Knows enough about what's actually going on under the hood to predict and avoid the relevant issues(SSD wear, odd cases where disk latency makes major slowdown, etc) * Understands the relevant details of the domain, like algorithms and math if they do that kind of work, or common hardware issues if they do embedded, etc. * Understands at least the basic level of application level stuff and what u…

* Doesn't secretly despise software, find ways to sabotage features, and wish we would all follow the guidance of Industrial Society and its Future. What if I agree with the first and third parts but I don't sabotage features?

Then you're begrudgingly a good programmer against your will?

Re: What does it take to be a good programmer?

#107

Post by BirAdam »

onion2k wrote: post #51
BirAdam wrote: post #8

Earlier quoted context omitted.

The single most useful thing I ever learned was how to break down a problem, make steps to a solution, make a flowchart of said steps, and annotate the flowchart with pseudo-code. After that, making the software was trivial. Even with that toolset I’m likely mediocre at best.

make a flowchart of said steps This is how you end up with software that does the job it needs to do perfectly well when all of the expected inputs and environment are correct, but completely fails if anything unusual happens, because 'it wasn't in the flow chart'.

That’s why things go through QA.
Post reply on HN