Live data from Hacker News

How to Succeed as a Poor Programmer

psgraphics.blogspot.com

41–50 of 196 posts

Re: How to Succeed as a Poor Programmer

#41
post #21

This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer. Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error. Most importantly - poor programmers do not learn from their mistakes a…

> Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error. All of these examples make sense in the context of your business, but in some environments these might be best practice ;)

> but in some environments these might be best practice

What are those environments? Can you be more specific?

Re: How to Succeed as a Poor Programmer

#42

Earlier quoted context omitted.

6. Be aware that most coding advice is bad. Think about whether there is empirical evidence that a given piece of advice is true.

In other words, "Only I hold the real keys, everyone else is lying to you. Trust only me." No, sorry. Invalidates the entire post, #3 notwithstanding. Such a cheap, low effort, lazy cop-out when writing about any topic. What the hell was this guy thinking? I'm certain he's got better wisdom to share than this.

Personally I don't think that's necessarily what he meant, and I don't think it invalidates the entire post. I do wish he added more detail though. He doesn't come off as an asshole to me, like your comment seems to imply.

If he were to say that most coding advice was noisy... I mean, I get that feeling too. There's lots of different approaches to the same problem that work in different scenarios, different work environments, domains of expertise, constraints, etc. And yet lots of coding advice is similar to, " do X". Unilaterally. Period. And you will end up receiving lots of conflicting advice.

It seems like the smarter thing to do is take everything with a grain of salt. You don't have to change everything you do as soon as you read a new blog post, it's just a different approach you could add to your toolbox, then use it someday if it makes sense.

Re: How to Succeed as a Poor Programmer

#43
post #20
post #2

Two things jump out to me: > Only learn something new when forced I think there is a balance between always doing things in a new way, versus always doing things as you've done before. When engineers are pushed too hard on deadlines, some will avoid learning new things as a short term approach for quick delivery. If your in that environment, you aren't going to grow. > Avoid linking to other software unless forced. I…

I used PHP where everyone would reinvent the wheel and JS where everyone would install hundreds of packages. This gave me the feeling that the truth is somewhere in-between. Maybe NPM packages are overall low quality and it would be okay to use more of them if they were better, but I'm now just installing a package when I don't have the time or skills to code it myself. This saved me from dependency hell, but it also…

I feel like rails is the good in between. It contains loads of helpful functions and tools to get 90% of the stuff you need done but its all part of one package so its all tested together and comes from one trusted org rather than 1000 random js devs.

Re: How to Succeed as a Poor Programmer

#44

I totally agree with this stuff. I was a professional programmer (now retired), and not a very good one. I'm familiar with Dunning-Kruger; I've worked with good programmers and bad ones, and I can tell the difference. Very good programmers are far and few. I noticed that most of my colleagues were keen to learn new shit, like new JS libraries, new languages, new source-code management systems and so on. I think I los…

> you can stuff Node and that ridiculous dependency system where the sun don't shine.

You're really taking embedded computing to the next level

Re: How to Succeed as a Poor Programmer

#45
> If you are bad at programming, you are still programming, something that very few people can do.

That's heartening. I bet a very bad doctor or lawyer can still do some good somewhere too, as long as they don't convince themselves they are better than they are.

Re: How to Succeed as a Poor Programmer

#46
post #40

I’ve been in a rut lately. Missing obvious things, shipping less than my best code. It’s come to my attention that I’m not as good at programming as I am at crafting database queries and tuning them but that’s such a small niche given how easy it is to pick up SQL that I’m having an existential crisis. So I’m working on getting better and getting more confident.

It's easy to pick up anything. It's difficult to master most. If you're good at SQL, why not transition to be a full-time DBA? In the right companies, good DBAs are highly valued. I suspect there is quite some business helping companies wanting to transition from Oracle or MongoDB to PostgreSQL.

I was a SQLServer DBA for a while and found the administration of things so boring. It was the crafting of queries and the designing of schemas that was the most fun.

If the administration part is a necessary tax to be paid then so be it if I get to do the other part.

Re: How to Succeed as a Poor Programmer

#47
post #21

This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer. Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error. Most importantly - poor programmers do not learn from their mistakes a…

Awareness is one important part of self-improvement, but taking the initiative and doing something about it is another thing.

Re: How to Succeed as a Poor Programmer

#48
Rather than Avoid Learning Anything New, I'd say avoid implementing anything new. Options always come in handy, you don't need to implement every new tech you learn about, but knowing it exists can make the difference between an impossible feature and a possible one

Re: How to Succeed as a Poor Programmer

#49
post #21

This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer. Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error. Most importantly - poor programmers do not learn from their mistakes a…

A poor programmer wouldn't be on HN and the point about never learning anything new reinforces that. Most of the article reads like satire.

Re: How to Succeed as a Poor Programmer

#50
post #21

This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer. Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error. Most importantly - poor programmers do not learn from their mistakes a…

I know many a poor programmer. The consistent thread between them is that they don't appreciate the fact that they don't know everything. You may be very well versed in a tech stack, but there are undoubtedly architectural implementations or design choices or algoritms which you simply don't know or haven't considered. A good programmer recognizes the situations where they cannot come up with the best solution and makes the necessary safety changes so that when the best solution does reveal itself, it's easy to swap out the old solution.

Another trait is the belief that they either never need to touch their code after they write it, or worse, only they will ever touch their code. It fires me up to see code that was written with the complete intention of never coming back to it again, despite the fact that it has to be maintained to keep the business running - reports have to use the data it generates, other applications have to use it's services because we can't afford to keep re-implementing everything. I also really hate seeing code that seems like the dev locked themselves up in their basement for a decade to write it. All sorts of custom switches, hardcoded configuration values, experimental tech embedded so deep the only graceful way to relieve that debt is to nuke it.

Post reply on HN