151–160 of 196 posts
Earlier quoted context omitted.
"All new ideas are bad" seems equally bad as advice.
"Wait for technologies to mature" sounds like a great heuristic for people who need to build things that actually work.
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…
It is phrased a bit ambiguously for shock value, I think.
I guess what he's trying to say is Avoid Learning Anything New if it's ancillary to your job, and instead focus on your core competences.
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'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…
It sucks when this is happening to a production system, and then maybe it's a mentoring & leadership problem instead.
> Only learn something new when forced This could be devastating, much more in little/medium company. I know of successful companies (I mean company with successful products ) with a C/C++ stack they considered "good enough" so they didn't change anything: the C++ standards, architecture, structures. Often that line of conduct was supported by a management looking any change or improvement as a cost. The result is al…
Just because something is old or uses old framework or old standard doesn't make it crap. Crappy code is crap, but it age doesn't make it crap. Code doesn't rust or detoriarate by itself. Example if you write good code now using C++14. If it's good code now it will continue to be good code 20 years later. There's no property that adds bugs or "crappiness" to the code as the years go past. The invention of a new "c++4…
I was all curious to read about monetarily poor programmers. Instead, this. I agree with part of it. The goddamned arrays really trigger my Refactoring Legacy Code PTSD though. Any time you make an array, you need to make sure that damn thing is big enough. Do you even know in advance how big that bastard needs to be? You could make it just plenty big, I suppose, like an asshole. Just allocate 10,000 4-byte blocks li…
[0] $7k per annum take-home-pay.
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…
Absolutely agree with mastering SQL. Out of all of the languages I have learned over the years, only one has stayed important in every job and mostly static - SQL There are many languages and libraries, but at this moment in time, all of them have to talk to a database at some stage, and in order to do that all of them convert the request to SQL.
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…
Reminds me of a programmer I met about 7 years ago. He was in a team of 4, writing internal software tools for a company. He said he was annoyed that he always had to manually join other peoples code. They would send the files they changed to him, and then he would search what changed, and add their changes to his own code. I asked why they didn't use source version control like Subversion. He asked me what it was. H…
Example: "We're doing a combo-box component, but to keep it simple let's not support multiselect."
Retrofitting such a feature when You Eventually Do Need It(YEDNI?) is neither pleasant nor simple.
My take is that one's skill level is not the most relevant thing - we have code reviews to deal with exactly this problem.
What ultimately matters is whether you're adding or subtracting value.
I've worked with people who were aggressively incompetent. As in: they had bad ideas and were insistent on implementing them, even going as far as bypassing the regular review cycle.