Live data from Hacker News

How to Succeed as a Poor Programmer

psgraphics.blogspot.com

61–70 of 196 posts

Re: How to Succeed as a Poor Programmer

#61
post #58
post #10

Earlier quoted context omitted.

If you read what he actually wrote, he obviously means "Avoid Learning Anything Newly Invented/Created" not "Avoid Learning Things That Are New To You". In that context, SICP, Java, and Linux hardly count as new...

That's a charitable interpretation and good advice, but they specifically say "Only learn something new when forced" and give two examples 25 years apart. It certainly sounds like they aren't learning technology as it matures but literally as they are forced.

I don't know why so many people here assume that learning something ages ago and sticking with it is mutually exclusive to learning anything tangential. Those two examples are programming languages and their accompanying ecosystems, not switching those for 30 odd years is not an indicator of having stopped learning anything.

Re: How to Succeed as a Poor Programmer

#62
post #41

Earlier quoted context omitted.

> 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?

There are plenty of environments where deviating from spec (even when fixing an apparently trivial bug) would not be ok without assessing the situation for potential unintended behaviors.

High-risk systems where a software bug could result in loss of life - aviation, submarine tech, defense, medical etc. Edit: This is for throwing exceptions on undefined behavior.

For unlimited threads I imagine scenarios exist particularly when scalable computing is so popular. Large high traffic web stores such as Amazon/Ebay, financial institutions, etc. Either way, the problem shouldn't be solved by an individual developer on a project making things up as they go - its a problem that probably needs to be defined at a framework layer, and discussed within the team of developers and requirements definers.

Re: How to Succeed as a Poor Programmer

#63

ALAN. Avoid Learning Anything New Terrible advice and mindset, It's good to learn for pleasure or curiosity. This way, you can enjoy reading SICP, effective java, code complete... Or you can use a new system, Linux, Mac, Android, iOS. Doing it you model your thoughts and mind, learn new ways, practices, or patterns, you don’t have to use then only for having learned, but even so, they will be useful to you.

Yes, it's a terrible, second-stringer attitude. Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass. TBH, if someone's only in it for the money, they're wasting their life in the wrong field when they could be doing something else such that their morale and satisfaction would be greater.

> Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass.

Unit tests and sensible comments are a couple of the key differentiators between a workaday jobber in it for the money and a badass. And now what? While I kind of agree that some people might be in the wrong job, that's true for every profession and the comparison seems lacking. If we're talking day job programming, a badass is neither a requirement, nor desirable in most environments honestly.

Re: How to Succeed as a Poor Programmer

#64
post #42

Earlier quoted context omitted.

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 envi…

He's not an asshole, but he gave in to the lack of any kind of rigor required to make a blog post. We're all guilty of it, but I hope we're all also willing to call each other on it.

Re: How to Succeed as a Poor Programmer

#65
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…

Learning is pretty simple, the golden rule is "Don't learn new tech, learn how to solve new problems".

Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API.

A better example might be something like Postgres and DynamoDB, since it can go either way. If your problem is 'I need a database for a CRUD app' then learning the second one is stupid because they both solve that problem just fine. But if your problem is 'I have a complex use case, my data is in a bad format for the one I'm using and I'm taking a huge hit in performance' then learning the other one is a reasonable choice and probably not a waste of time.

Basically whenever you take the time to learn something, make sure you're getting something out of it in terms of end results. It feels good to just learn more of the same tech, and if the API is different enough it'll feel like you're making progress, but you're probably not.

Re: How to Succeed as a Poor Programmer

#66
I think the best way to make it as a 'poor programmer' is be a domain specific 'poor programmer'. I am bad a nearly all my programming in all my projects but probably just as efficient at getting jobs done than a 'good programmer' because the feedback loop is fast. I can hack away until something works and then sometimes polish it off when it functions. I suggest work using really popular tools and there is usually a solution written up online easily found through Google. Such are the times.

Re: How to Succeed as a Poor Programmer

#68
> 4. Make arrays your goto data structure.

The others are arguable. But, in 2019, this is flat out bad advice.

Your "go to" data structures should be hash tables about 70% of the time and vectors about 30% of the time. In 2019, memory and CPU are so stupidly abundant that the abstraction costs nothing in 99.9% of all cases. The programmer gain for not having allocation, dereference, fencepost, and invalidation errors is enormous.

But, then, this is hardly surprising advice from someone who only learned about a "scripting language" in 2015. The rest of us realized that those silly "scripting languages" were better than C++ for 90+% of our problems way back in 1995.

And anyone who has used a "scripting language" realizes extremely quickly just how stupidly useful hash tables are.

Re: How to Succeed as a Poor Programmer

#69

ALAN. Avoid Learning Anything New Terrible advice and mindset, It's good to learn for pleasure or curiosity. This way, you can enjoy reading SICP, effective java, code complete... Or you can use a new system, Linux, Mac, Android, iOS. Doing it you model your thoughts and mind, learn new ways, practices, or patterns, you don’t have to use then only for having learned, but even so, they will be useful to you.

It depends. Some things are visibly awkward, unpleasant to learn and use, and clearly short-lived. It only pays to learn and work on them if you are paid a lot of money. My pet example from the 1990s is Win16, which I skipped entirely for Win32. Many 4GL languages from the 90s stayed there too. Every second of time dedicated to Javascript frameworks before React/Vue was probably a waste of time. (OTOH learning the bare-metal JS paid off well.)
Post reply on HN