Live data from Hacker News

What does it take to be a good programmer?

qristin.wordpress.com

41–50 of 107 posts

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

#41

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.

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

#42

Earlier quoted context omitted.

You sound bitter and resentful. Also, student loan debt is not a requirement for becoming a programmer. I have student loan debt, but that's because I decided to go to law school before switching to software development :)

>You sound bitter and resentful Nope, I like what I do, and talking with the engineers I work with everyday. However, you are about to climb a mountain I've already ascended before, and can't understand my perspective yet. You will start fantasizing about being a plumber soon... it is the logical choice after all.

I've no idea what you're talking about and I suspect other people you meet and interact with (at least online) will feel the same way. I know this might sound harsh, but that's my feedback in the event you're at all interested in communicating more effectively online.

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

#44

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?

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

#45

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-source code usually takes longer than just writing the small part of their library that I need, and it doesn't involve having to argue with them, or have my PR rejected, because I have "too many comments."

I know that's not a popular stance, around here, but it works for me. I use a ton of dependencies, in my work, but I wrote most of them.

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

#46

I just want to say, I'm really glad that we are talking about "programmers". I hate that stupid term, "software engineer". What a ridiculous title. As if programmers do not also engineer software. And then what are "software architects" for if you already have "software engineers"? Sorry for the off topic rant.

In companies of a certain size the differentiation between these (or similar titles) get more clear. In my opinion they are also strongly linked with experience (in certain areas).

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

#47
I have to admit, some of the absolute best programmers I've personally known, seemed to share these qualities:

- Natural curiosity, exploring all kinds of technical / scientific topics - not necessarily programming alone.

- Extreme eagerness to learn. I'm absolutely not the kind of guy that can just immerse myself in technical books, but these guys are the types that would dedicate their spare time to really read and understand relevant literature.

- Intellectual acumen to easily pick up concepts. This was especially apparent when you studied with them - and could see how they compared to the rest. While others would struggle with some topics for weeks, even months, some of these would pick them up in the mater of hours. But I also think this is equally due to having strong background, and really knowing the fundamental stuff.

- Strong discipline. Showed up to work / school / etc. every day, put in all their hours. Little slacking around.

- Willingness to discuss and teach others. On the contrary to the "arrogant genius" stereotype, most of the really strong people I know have been eager to teach or show - at least as long as the interest has been genuine.

Probably forgetting a lot of stuff - but those have been some of the patterns I've noticed. The really good programmers and engineers I know have spanned from high-school drop-outs to research scientists.

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

#48

Earlier quoted context omitted.

>You sound bitter and resentful Nope, I like what I do, and talking with the engineers I work with everyday. However, you are about to climb a mountain I've already ascended before, and can't understand my perspective yet. You will start fantasizing about being a plumber soon... it is the logical choice after all.

I've no idea what you're talking about and I suspect other people you meet and interact with (at least online) will feel the same way. I know this might sound harsh, but that's my feedback in the event you're at all interested in communicating more effectively online.

This is not an industry for the emotionally sensitive, sanctimonious, or petulant.

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

#49

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…

> Uses commonly accepted approaches, libraries, style I would argue NOT to do this if you're writing Java. Java paradigms are awful, lead to way too many layers of abstraction, and code that is impossible to debug because your stack traces are just 30 calls of ".invoke()". > Readable by programmers who'll work with that code in the future. And yet Perl became popular.

Java was the language of choice when I was at university. The way they described it to us, was that everything about it was designed with teamwork (and large teams) in mind. I don't know how well it really did that even by the standards of the era of its introduction, but it has the air of plausibility.

Certainly, I expect anyone who is used to that style to prefer to encounter and work with Java written in that style over Java written in the style of C.

> And yet Perl became popular.

As I recall, the joke being that it was a "write only" language.

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

#50

Is it the same thing a being a good software engineer? I've got relatively limited experience working a software engineer but to my disappointment, it seems more than 70% of my job isn't programming. Most of the work is discussing priorities, making tradeoffs, interacting with colleagues and management, writing design documents, giving feedback, writing doc, maintaining, benchmarking, and debugging services, learning…

This is true.
Post reply on HN