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

51–60 of 107 posts

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

#51

Post by onion2k »

BirAdam wrote: post #8
revskill wrote: post #2

I teach programming, too. My way of teaching is not much about computer, it's more about thinking, drawing and writing (not only code). - Thinking about steps, divide and conquer. - Drawing or visualizing the steps. - Writing documentation clearly before any code is written. Most of new programmers tend to think just make program work means DONE. No, it's not, it's just the last part of what to be done.

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'.

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

#52

Post by ArcMex »

I enjoyed this article. I echo many responses here and some of what’s in the article to reaffirm their importance in not just being good, but successful.

1. Clear communication

2. Thinking thoroughly about the problem and the solution

3. Easy to maintain code

4. Testing

5. Documentation

6. Research and learning

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

#53

Post by eternityforest »

gadflyinyoureye wrote: post #41
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…

I'm not going to go so far as to promote violence, by I disagree about despising software. There is a lot of software out there that should/could be replaced with simple process changes. If you despise software enough to know that it is not right tool for the job even when you are a programmer, you can safe yourself, management and users headaches by avoiding writing a line.

I'm not sure I've actually seen this IRL. I've seen cases where new custom software is the wrong approach(Actually, that's most of the time), but usually it's because there's some existing software that can already do whatever it is.

There hasn't been many times when I've seen something that people would normally use software for, and willingly chosen a process that isn't primarily software driven. I think the one of the only times is when dealing with physical tasks in personal life, I'll usually put up reminder signs like "Check lint trap" rather than use to-do list software.

Even then I'll use my Bluetooth printer to make the sign so it looks nice and neat....

The other case is tabletop RPGs, I've yet to see any tech at all that doesn't completely ruin immersion for non-scifi games, phones are very culturally charged objects that can instantly change the mood to "Screen staring club".

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

#54

Post by pards »

> I don’t care how good you are at chopping vegetables, how efficiently you handle the ingredients while cooking or how modern your kitchen appliances are – if the food tastes like crap, I’m not coming back to your restaurant!

This. Your users/customers don't care about your tech stack, pipeline, deployment model, or test coverage. They want software that works and doesn't get in their way.

Your tech stack, pipeline, deployment model, or test coverage might support producing software that works and helps the user, but it's a means to an end.

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

#55

Post by randomdata »

Sohcahtoa82 wrote: post #31
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.

Yeah, to me, that's all programming is. Taking a task, breaking it down into tiny steps, and writing those steps down in a language a compiler/interpreter can understand. The problem is trying to break down MASSIVE problems. Back when I was frequently dealing with newbie programmers, it was common to find ones that wanted to make an MMORPG while they could barely grok for-loops. They hadn't even completely understood…

How would you begin to understand programming (or anything for that matter) without first starting with a massive undertaking and breaking it down into smaller chunks that can be discovered? Give someone a for-loop in isolation and it means nothing. They will never really understand it because it doesn't relate to anything. Given something massive they will have to break it down, and in that it will dawn on them "Huh, I need to do this same thing over and over again. I wonder how I might do that?" at which point they will discover loops, and then it will make perfect sense.

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

#56

Post by eloisant »

pards wrote: post #54

> I don’t care how good you are at chopping vegetables, how efficiently you handle the ingredients while cooking or how modern your kitchen appliances are – if the food tastes like crap, I’m not coming back to your restaurant! This. Your users/customers don't care about your tech stack, pipeline, deployment model, or test coverage. They want software that works and doesn't get in their way. Your tech stack, pipeline,…

Yeah but if you're too slow at chopping vegetables and I have to wait 1 hour to get my dish, I'm not coming back to your restaurant either.

To produce software that works and doesn't get in the user's way, and not introduce regressions every other day, caring about your tech stack, pipeline, deploy model etc matters.

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

#57

Post by jrumbut »

contravariant wrote: post #36
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…

While those are all good guidelines (though I'm not too sure about 6) a 'master' programmer should probably know when to break each of those rules. In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems…

One of the aspects of mastery (that I've observed in others) is being able to say yes to 99% of requests but knowing how to steer projects away from that one feature that will cause complexity to explode without delivering commensurate value.

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

#58

Post by hbrn »

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.

This is a really good point. Engineers are constantly trying to predict the future, but ability to do so often does not depend on engineering skills at all. Often it is completely out of your control.

Instead of trying to make code "extendable" I found that it is much better to make code "disposable".

Do not hope you'll make the right prediction. Expect to be wrong and be able to recover fast.

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

#59

Post by mellosouls »

ChrisMarshallNY wrote: post #45
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…

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-sou…

That's fine if nobody else has to maintain your code.

If they do it's difficult to see how your solutions to solved problems aren't going to be significantly more problematic and risky than established libraries.

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

#60

Post by bob1029 »

ChrisMarshallNY wrote: post #45
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…

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-sou…

This is our stance too.

Even within the "batteries included" aspects of the .NET6 framework, we insist on doing certain things our way.

Some of the biggest examples being AspNetCore logging and the JSON-style configuration abstractions. We completely rip this out and do it in code-time our way. I cannot account for the exact number of hours we wasted trying to do [x] the 'official' way only to be burned at deployment & framework upgrade time. It took at least 100 hours just to realize json-based runtime config is definitely not for us.

Separately, it took me fewer than 30 minutes to write a dumbass static logger that fills a sqlite database with entries and have it wired up throughout the application. I don't think you could even read & understand that AspNetCore logging article in 30 minutes, much less have functional code in place that you can hang your hat on for years to come.

If not reinventing the wheel is about saving time, then perhaps we need to iterate the aphorism. Maybe we flip it around: Only reuse other people's code when it's for something that you don't really care about or doesn't frustrate your project's long-term ambitions.

Post reply on HN