Live data from Hacker News

How to Succeed as a Poor Programmer

psgraphics.blogspot.com

161–170 of 196 posts

Re: How to Succeed as a Poor Programmer

#161
post #149

The "Avoid Learning Anything New" advice is insane. (Well, practically all of it is, but that one really stands out). I think the exact opposite advice is far better: never assume the way you know how to do something is best, and always be on the lookout for what others are doing that might be better. Here's the thing about learning: the more you learn, the easier learning the next thing becomes. You form links, insi…

He's a C++ programmer, so I assume he can also code in C. So do I. When you go so low-level, then everything else just translates to "overhead" and it's always a trade-off (for example exchanging performance with "fast coding" or "easy of use"). At that point, you know there is nothing better, if better is understood in terms as "performance" (I develop firmware), so there is little room for improvement. Maybe rust?…

> He's a C++ programmer, so I assume he can also code in C.

I would make no such assumption. Most C++ programmers I've known would have a hard time being productive in a language where they had no collections, templates, virtual functions, destructors, lambdas, exceptions, etc. Trading deep knowledge of how C++ manages memory for knowing how to do it yourself might be even more of a challenge. A lot of C++ programmers know C because they were around as the two evolved, but at this point there are many who entered the profession with C++ and would find C almost as confounding as COBOL.

Re: How to Succeed as a Poor Programmer

#162
post #16

Earlier quoted context omitted.

It's not terrible advice. You mentioned SICP, funny thing is, years ago when I put someone on to SICP, next thing you know in our production code we started getting these weird ass recursive functions..... Also had similar issues with Design Patterns, all kinds of overly engineered class structures started popping up. On the side of ALAN, I used to work with guy who did a lot of machine vision research, he coded ever…

But doesn't putting somebody on SICP in the hopes of helping them learn functional programming (is that SICP's concern?) sound to you as... aspirational advice? The book is as famous as it is infamous.

the point is more that anything you learn, you often want to try out the new toys. But those toys aren't your A game and we haven't learnt the lessons yet of applying things to achieve real results, so often that can skew our productivity. Whole new frameworks can leave us completely incapacitated when we hit the edges of what is commonly done until we either dig through things ourselves or find someone to answer our questions.

Re: How to Succeed as a Poor Programmer

#163

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.

While it might be a bad rule as stated, I took it as a tongue-in-cheek way of getting at a much better rule: Avoid Learning Everything New. Or maybe, for the sake of a better acronym, Stop Learning Ephemeral Dreck. It's certainly good to expose oneself to new ideas. Sometimes it's worthwhile to dive deeper into something different. The problem is that a lot of programmers make neophilia into a lifestyle, forever distracting themselves and never learning anything really well. Scratch the surface, get some quick wins at something that's still new to everybody, move on to the next thing. Avoid any domain or technology where true experts can show you up. That's just another way to succeed as a poor programmer. Good programmers have at least some breadth and some depth in a few areas.

Re: How to Succeed as a Poor Programmer

#164
post #95

The "Avoid Learning Anything New" advice is insane. (Well, practically all of it is, but that one really stands out). I think the exact opposite advice is far better: never assume the way you know how to do something is best, and always be on the lookout for what others are doing that might be better. Here's the thing about learning: the more you learn, the easier learning the next thing becomes. You form links, insi…

He is right though – new tech nearly always disappears. Example: Learning CoffeeScript was a total waste of time. Learning JQuery helped me for a few years, but now JQuery is basically useless to me. Based on past experience, I strongly suspect the same will happen with React, Rust and a bunch of other new exciting tech. There are countless examples besides the ones I mentioned. But on the other hand, the time I put…

So yeah, React may go away in three years. Do you think you would have been better off during those three years continuing to use jquery? Do you think the hours spent learning the new thing were more or less then the hours saved my the new thing having a better api?

(now, of course, you I may be wrong on the cost benefit analysis here. I don't think I am, and the ubiquitousness of the new stuff implies that most of the industry agrees... but no matter the answer, that is the way to think about whether learning something is worth it)

Re: How to Succeed as a Poor Programmer

#166
post #95

Earlier quoted context omitted.

He is right though – new tech nearly always disappears. Example: Learning CoffeeScript was a total waste of time. Learning JQuery helped me for a few years, but now JQuery is basically useless to me. Based on past experience, I strongly suspect the same will happen with React, Rust and a bunch of other new exciting tech. There are countless examples besides the ones I mentioned. But on the other hand, the time I put…

> Learning JQuery helped me for a few years, but now JQuery is basically useless to me. 'A few years' is a solid return on investment. Besides the reason Jquery is now useless is because Javascript now has those capabilities, so your skills were 'grandfathered' to ES6/ES7. Learning an applicable skill is almost never useless.

I made the switch to vanilla JS from jQuery a year or so ago and it's great to see how jQuery (and other libs) pushed vanilla in certain directions. But I'll always miss $('#element') vs getElementById('element') and similar shortcuts.

Re: How to Succeed as a Poor Programmer

#167
post #149

Earlier quoted context omitted.

He's a C++ programmer, so I assume he can also code in C. So do I. When you go so low-level, then everything else just translates to "overhead" and it's always a trade-off (for example exchanging performance with "fast coding" or "easy of use"). At that point, you know there is nothing better, if better is understood in terms as "performance" (I develop firmware), so there is little room for improvement. Maybe rust?…

> He's a C++ programmer, so I assume he can also code in C. I would make no such assumption. Most C++ programmers I've known would have a hard time being productive in a language where they had no collections, templates, virtual functions, destructors, lambdas, exceptions, etc. Trading deep knowledge of how C++ manages memory for knowing how to do it yourself might be even more of a challenge. A lot of C++ programmer…

In the article he says he learned C++ in 1995, so he probably knows C.

Re: How to Succeed as a Poor Programmer

#168

Earlier quoted context omitted.

> He's a C++ programmer, so I assume he can also code in C. I would make no such assumption. Most C++ programmers I've known would have a hard time being productive in a language where they had no collections, templates, virtual functions, destructors, lambdas, exceptions, etc. Trading deep knowledge of how C++ manages memory for knowing how to do it yourself might be even more of a challenge. A lot of C++ programmer…

In the article he says he learned C++ in 1995, so he probably knows C.

[deleted]

Re: How to Succeed as a Poor Programmer

#169

Earlier quoted context omitted.

I dont mean to be offensive, but usually those things take like a month to learn if you're bad at it. People talk about that grind like it's anything other than the most basic of gestures for tracking the rapidly moving target of browser technology. If this is what we mean by, "being a bad programmer" I guess I get it now. A refusal to actually track the state of the industry, instead being told by employers what mat…

> A refusal to actually track the state of the industry, instead being told by employers what matters. Yeeees... so instead of being "told" by your employers, you're "told" by the hype-train? How exactly is this better? Being fed up of the constant churn in JS frameworks is an entirely valid position. Sure, maybe it only takes a month to learn the latest framework. Maybe it only takes a couple of weeks. But maybe I'd…

> Yeeees... so instead of being "told" by your employers, you're "told" by the hype-train? How exactly is this better?

Because occasionally our peers are right? Do you really have so little respect for everyone in the industry around you that every new piece of tech that comes along, you just assume it is a mass of incompetence and marketing?

A diversity of perspectives, ideas and approaches is a fertile ground for personal growth. There are never any shortages of such hype trains.

And at least they're made by fellow software engineers. Not, you know, corporate hiring comittees.

> And what about all the gotchas and quirks that every framework has? The pathological performance edge-cases, and suchlike? The ones you only discover after weeks and months of in-depth use? I'll have to learn a whole new set of those.

Getting domain specific, you'd be doing that anyways because of how rapidly browsers are growing and changing.

> And what about my "legacy" codebase that used the last framework du jour. Do I just ignore it? Do I convert it? Hmm. Wonder how long that will take, and what else I could be doing with that time.

> Maybe you enjoy the churn: endlessly learning useless knowledge that will be of no value to you in a few short years because it's no longer trendy. Lucky you.

Why is it that the value of software is defined by if it is trendy 5 years later? That's a conflation of concerns I can't follow.

> For me it got boring, because I've got stuff to build.

For me, squatting on one stagnant pile of never-really-that-good technology building the same boring things over and over again at the behest of others is equally boring.

You suggest all the frameworks are poorly designed hype, but then decide you want to take an arbitrary moment in time (when you showed up, that fated day) and freeze everything there.

That reasoning seems unconvincing.

Re: How to Succeed as a Poor Programmer

#170
post #140

Earlier quoted context omitted.

I dont mean to be offensive, but usually those things take like a month to learn if you're bad at it. People talk about that grind like it's anything other than the most basic of gestures for tracking the rapidly moving target of browser technology. If this is what we mean by, "being a bad programmer" I guess I get it now. A refusal to actually track the state of the industry, instead being told by employers what mat…

If you're unnecessarily spending a month a year on platform churn, that's nearly 10% loss of productivity right there. Doesn't seem like a good choice to me, unless you're genuinely gaining something important.

This was about learning, not re-engineering. Why are you conflating the two.

Lest we forget, the opening post advised you never learn anything new.

Post reply on HN