I wished he just used the word 'bad' instead of 'poor'. I thought this is about cash-strapped programmers.
How to Succeed as a Poor Programmer
121–130 of 196 posts
Re: How to Succeed as a Poor Programmer
#122If "Be aware that most coding advice is bad." is true, then how confident should I be that this "How to Succeed as a Poor Programmer" coding advice is good? ;)
Re: How to Succeed as a Poor Programmer
#123Earlier 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 CoffeeScript was only a waste if you never got paid to write / never built anything useful in CoffeeScript. The failure there is learning something that is not useful to you right now , not "learning something new". Are their opportunity costs associated with learning one thing over another and making the "wrong choice" in terms of which stuck around longer? Sure. But you can't predict the future. Focus less…
Exactly. Also, things keep getting reinvented, often with something beneficial added but usually also something worse than what we used to have. So the perspective of past knowledge can often help you understand some aspect of the new stuff, if you’re also correspondingly open-minded enough to learn the new thing on its own in advance.
And recent experience has shown me that you can both be working with the worst legacy code and CGI has to throw at you and also having to learn pre-release ECMAScript and TypeScript, to use on the same project. Some skills transfer — I’ve never had to fully relearn how to loop through something in a new language once I managed to master both for loops and map/each functional approaches, for example.
Other things are maddeningly poorly developed — tools to help you understand and refactor code are still very much language-specific at the moment and it’s always a one-off to port out-of-fashion languages and syntax to newer ones. Let’s not start on how testing guidelines and TDD haven’t significantly changed since 2003 unless you maybe include SRE work and better “testing in production” techniques... Some knowledge seems evergreen... or stale.
But it’s amazing how when you do keep an open mind, and focus on how something really works at a lower level, it still pays off over time. I still haven’t deployed anything in production with Docker and K8S but that doesn’t mean it wasn’t worth learning, it helped clarify that there’s more to production reliability than simple deployment scripts or imperative commands vs declarative repos — simply knowing it helped me better understand related topics, including additional reasons why immutable, fully-reproducible build systems are a good thing, or how deployment can be seen as a complete system instead of simply “what version of the code is on the servers now?” It also provides a promise of a cloud-agnostic future, and an alternative look at why 12-factor was good, but incomplete.
And there, again, one might say, why did you bother learning 12-factor when most places let you store log files on local EC2 drives, for example? Well, because if you can get over the information overload, having multiple ways of doing things means you’re more likely to be flexible in your approach, or ask “why” when someone says “just do it this way”. It of course has to be balanced with healthy pragmatism, to both ignore the “best option” when it’s too much work, or to recognize that there’s always a chance to continue improving things later on, or as a team.
What’s key is trying to think strategically about your code rather than tactically. A tactician would say “learning nothing new outside of what I need at this moment gets the job done faster” or “this fixes the bug” while a strategist recognizes that there’s always a future opportunity cost, or asks, “but what caused the misunderstanding that allowed it to occur in the first place?”
Also, it’s inevitable that things will change, so you should always either keep up with your specialty or keep expanding your generalist skill sets. And even your knowledge isn’t constant — there’s always something to re-learn if you haven’t used a thing in awhile or in some new way...
Re: How to Succeed as a Poor Programmer
#124Earlier quoted context omitted.
> 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.
Yeah, I'm not saying it wasn't useful at the time, just that it's not useful now. As opposed to learning SQL or shell scripting which will probably be useful my entire career.
I'm convinced of 'learn old > learn new' in general, but I think there are some interesting edges: the older something is, the larger the gap (maybe chasm) will be between 'basic competence' and 'venerable expert'. Also, the more likely all the common problems you'll face will have been posted on the internet, and that the quality of tutorials and explanations will be superlative.
While the payoff of learning old > new is typically much higher (search: Taleb Lindy effect), I think matching your learning to the 'human api' is more important. For me, learning is very emotional: when I feel a sense of curiosity and intrinsic drive to know, I'll follow my nose, spend my time where it takes me. I want to spend this kind of energy in a certain way.
When I find myself with an instrumental cause or external need to know, it's most likely going to be because it's something typical, something old, in which case learning about it and being useful with it will require less of my spirit and drive to crack.
New language/tech fanatics tend to pressure through both sources (a la "look at our ingenious design breaking paradigms" and "it's so good your boss will want you to work in it (well, soon)"). Often the former argument is stronger, so it appeals to your curiosity - in which case you're best off searching for the useful kernel, followed by a swift exit in order to preserve your sense of discernment. Should you return there, provoked by your general interest, that ought to be your indicator of importance. How hyped you felt that one afternoon you learned about it after reading HN comments is likely not.
On the other hand, the 'should learn' brigade will tend to target the latter source of pressure (employability & centrality). If you find yourself feeling resistant to this and force yourself into it anyway, you'll easily burn out and douse your curiousity for the day. I've arranged learning resources to languages I find fundamentally dull multiple times, and made only very shallow dives into them.
When choosing what to learn, your built-in heuristics will tend to serve you much better than either a long list of common 'shoulds' or a tangle of overhyped 'musts'. Let natural forces do their thing in shaping what things will be presented to you: avoid paying much attention to the loud people where marketing, shills and zealots tend to roam.
Re: How to Succeed as a Poor Programmer
#125> 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…
> Your "go to" data structures should be hash tables about 70% of the time and vectors about 30% of the time. I literally just wrote a comment elsewhere about how hash tables are obscenely overused and cause measurable performance degradation in many situations.
That may be.
However, the number of times I see people hit a bug because they fenceposted or flat out overflowed a fixed size array VASTLY outnumbers the times I have seen people have to redo their underlying data structure because it just wasn't fast enough.
Re: How to Succeed as a Poor Programmer
#126Earlier quoted context omitted.
You lost me at "next thing you know in our production code we started getting these weird ass recursive functions...". I don't mean to be mean, but recursion is pretty fundamental to a lot of algorithms, and it sounds like the SICP coder was just writing stuff more advanced than you were comfortable with.
Might also be an inappropriate application of recursion in a language where loops are more common. I've seen people who learn new stuff go overboard with clever code in production that is less readable for their peers. Recursion shouldn't even be considered advanced though, just like classes and first class functions. I'm all for making code as boring as possible, but to me understanding at least these concepts is a…
Sometimes recursion is the good solution, For example a back-tracking solution is more simple with recursion than without it.
Re: How to Succeed as a Poor Programmer
#127If "Be aware that most coding advice is bad." is true, then how confident should I be that this "How to Succeed as a Poor Programmer" coding advice is good? ;)
Yes.
Re: How to Succeed as a Poor Programmer
#128Earlier 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…
I prefer learn tech on demand: given a job find the right tools that exist at the time, and then use them even if you don’t already know them. Besides, having problem context makes the learning much easier, vs just saying...I’m going to learn react today in a void.
> given a job find the right tools that exist at the time
If you don't know said tools beforehand, how can you be sure they are right for the job? When building a new website, for example, should you reach for jQuery? Or is React right for the job? Or is Vue even more right? Or will it be Svelte? Or is vanilla javascript the tool that you really need? How would you know?
Re: How to Succeed as a Poor Programmer
#129ALAN. 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.
6. Be aware that most coding advice is bad. Think about whether there is empirical evidence that a given piece of advice is true.
Indeed, Usually, all coding advices are too emphatic or clickbait.
ex:
The 10 languages you have to learn in 2020.
The most important js framework.
The 10 books you must read.
But in reality, all advice depends, they depend on what are you doing, what you know, what is your experience....
Re: How to Succeed as a Poor Programmer
#130The "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…
Let me quote a friend that ranted about this very subject about a week ago: I am of extremely average intelligence. On the absolute top of the bell curve, looking down at the rest of you. I am extremely tired of the whole attitude that _anything is possible if you just put your mind to it_. I put my mind to it. That is how I got through CS in university. I worked at least twice as hard as the people that said _just p…
He might be right. But let’s not forget that experience plays a role. Whenever I think of creating crud apps now, I think “ah, easy”. I didn’t use to think that.
Some people start programming at a very young age, by the time they’re in college they have the ability to relate all kinds of concepts. An ability that I have as well now, which I obtained after my bachelor and used in my master.