How to Succeed as a Poor Programmer

The &quot;Avoid Learning Anything New&quot; advice is insane. (Well, practically all of it is, but that one really stands out).<p>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.<p>Here&#x27;s the thing about learning: the more you learn, the easier learning the next thing becomes. You form links, insights on relationships, new concepts that apply to old things, etc. If this guy thinks learning is such a burden, it&#x27;s probably because he refuses to learn anything in the first place.<p>If he thinks he&#x27;s a poor programmer, it probably has less to do with innate ability and 100% to do with the attitudes he gives as &quot;advice&quot; in this blog.

This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer.<p>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.<p>Most importantly - poor programmers do not learn from their mistakes and are unable to see that they are poor programmers.

It&#x27;s a great, succinct post. <i>Deeply</i> uncool. A programmer should be modest about their skills, skeptical about new-new things, eschew bullshit, and terrified of dependencies. I buy the whole thing.<p>Moreover, I trust the advice of someone who rates themselves poorly more than someone proclaiming that they&#x27;re a hotshot.

ALAN. Avoid Learning Anything New<p>Terrible advice and mindset, It&#x27;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.

Two things jump out to me:<p>&gt; Only learn something new when forced<p>I think there is a balance between always doing things in a new way, versus always doing things as you&#x27;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&#x27;t going to grow.<p>&gt; Avoid linking to other software unless forced. It empirically rarely goes well.<p>Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise.<p>I was hoping this would talk about how to support your co-workers (code review, culture, cohesion) or how to succeed at non-engineering tasks other &#x27;good&#x27; programers may overlook

&gt; Only learn something new when forced<p>This could be devastating, much more in little&#x2F;medium company. I know of successful companies (I mean company with successful products ) with a C&#x2F;C++ stack they considered &quot;good enough&quot; so they didn&#x27;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 always the same: a day they wake-up realizing that the &quot;product&quot; is a pile of crappy legacy code. I know some cases. One of those company was bought by a bigger company that asked to modify the stack to modern standards with disastrous results because the programmers wasn&#x27;t skilled to port the code base to modern standards&#x2F;architectures. In another case, the owners sold the entire division to another company, interested to the clients more than to the product and, after checking the status of the code base, the buyers hired a group of consultants that rewrote all in Java, with results that you can imagine.

This is probably really bad but I totally empathize (and agree?)<p>KISS =&gt; everyone should do this<p>YAGNI =&gt; 95% of the shit I add is ignored (and I&#x27;ve got fairly objective proof that I can develop good projects)<p>ALAN =&gt; Master SQL, one scripting language, and how to use Stack Overflow. You&#x27;ll be the most useful dev on the team.<p>I agree with most of the rest.<p>Bonus point: never be afraid to tell a business person that what they want is an exceptionally bad idea. it usually is.

I don&#x27;t think most of this applies only to &quot;poor programmers&quot;.<p>The advice about KISS is something many &quot;good&quot; programmers would benefit from following. Likewise, I&#x27;ve seen good programmers recommend using arrays as your first attempt at a data structure as well (e.g. Jonathan Blow, <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JjDsP5n2kSM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JjDsP5n2kSM</a> )

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.<p>So I’m working on getting better and getting more confident.

I totally agree with this stuff.<p>I was a professional programmer (now retired), and not a very good one. I&#x27;m familiar with Dunning-Kruger; I&#x27;ve worked with good programmers and bad ones, and I can tell the difference. Very good programmers are far and few.<p>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 lost interest in newness (for its own sake) about 15 years ago; I got turned over one time too many by a vendor that decided to withdraw support for a programming language that I had committed myself to.<p>I recommend retiring from programming. You don&#x27;t have to keep up with the young whippersnappers any more, you can carry on coding in bash, you don&#x27;t have to use git, Docker, or weird NoSQL systems. I realise that some of this new-fangled stuff is better than FORTRAN or VB6 or whatever; but learning a new programming system every 6 months is a total waste of time and effort. Get to be good with a few useful tools, then concentrate on people skills.<p>Or give it up completely, and learn cooking, or drumming, or interior-decorating.<p>I think there may be some rationale behind ageism in software development. For the first 25 years or so I got better at it, but I think after I turned 50 I started getting worse. Or at least, I got better slower. It took me longer to learn new tricks.<p>But I really think that some of those new tricks were not worth learning - for example, you can stuff Node and that ridiculous dependency system where the sun don&#x27;t shine. JS is a very clever language; but cleverness isn&#x27;t always best.

If you ALAN you can&#x27;t KISS. You won&#x27;t know what the simplest thing is. You&#x27;ll end up with miles of nested &quot;ifs&quot; instead of 4 lines of recursion. A gazillion &quot;else ifs&quot; instead of case etc.<p>He&#x27;s got one thing right. He&#x27;s a poor programmer. &quot;Success&quot; must be mighty loosely defined here.

I was all curious to read about <i>monetarily poor</i> 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 like that shit just grows on trees. Then change it to 15,000 the first time someone has 10,001 things and crashes your shitty shit. Also any time you look at your shit you&#x27;re gonna need a goddamned shitty index. A whole &#x27;nuther variable! Get some generics ya dufus!

&gt; If you are bad at programming, you are still programming, something that very few people can do.<p>That&#x27;s heartening. I bet a very bad doctor or lawyer can still do some good somewhere too, as long as they don&#x27;t convince themselves they are better than they are.

I think the best way to make it as a &#x27;poor programmer&#x27; is be a domain specific &#x27;poor programmer&#x27;. I am bad a nearly all my programming in all my projects but probably just as efficient at getting jobs done than a &#x27;good programmer&#x27; 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.

Please don’t store everything in Arrays. If your language supports tuples, use them. If it doesn’t, at least use a struct if possible. Basically: Constrain the possible input and output space of your functions to the smallest amount of possible values. That way, you are reducing the room for errors significantly. Using arrays everywhere, many errors might even go unnoticed until an edge case occurs.

A very interesting post, since it poses one very conservative, tried and true approach to programming productively. I know a lot of programmers tend to arrive at those very same conclusions in their career. That said, I think the article and most of the commenters here don&#x27;t necessarily conflict with each other; every piece of advice can apply or not, depending on the circumstances.<p>On a larger scale, it&#x27;s remarkable that a lot of the general programming advice given today is more of a heuristic&#x2F;guide than a tautology, but many people still assert that their advice is The One Right Way To Do Things. It&#x27;s important to understand that the vast majority of all this advice comes from real examples of what worked and what didn&#x27;t. So, perhaps the best thing one can do as a programmer, in any domain, with any technology, whether you&#x27;re a great programmer or a poor programmer, is to listen to it all with zen and a grain of salt.

I dislike this mindset too. For any other profession it would be crazy, but for programming it&#x27;s fine? What happened to apprentinceship and mastering the craft? Why is it fine to be considered a fool if you are not an expert programmer from the start? Should a blacksmith never make a sword, because at the beginning they can only make nails?

This guy is poor because he is lazy as hell. The most important thing about programming is constantly learning new ideas, tools and paradigms, solving new problems, improving as a person and learning as much as possible. If you don&#x27;t do these, don&#x27;t like to think or solve problems, you will stay indeed poor.

Kids, trust your elders on this one, the author is correct.

With regards to &quot;Avoid Learning Anything New&quot; I would be very surprised if Pete Shirley follows that advice when it comes to things actually relevant to his job. People who avoid learning anything new don&#x27;t get to be senior researchers at Nvidia or have the following publication list: <a href="https:&#x2F;&#x2F;scholar.google.com&#x2F;citations?hl=en&amp;user=nHx9IgYAAAAJ&amp;view_op=list_works&amp;sortby=pubdate" rel="nofollow">https:&#x2F;&#x2F;scholar.google.com&#x2F;citations?hl=en&amp;user=nHx9IgYAAAAJ...</a><p>I guess what he&#x27;s trying to say is Avoid Learning Anything New if it&#x27;s ancillary to your job, and instead focus on your core competences.

&gt; Finally, let the computer do the work; Dave Kirk talks about the elegance of brute force (I don&#x27;t know if it original with him). This is a cousin of KISS. Hardware is fast. Software is hard.<p>Yeah, I don’t know. The cloud bill is going to be expensive.

One problem I have with 1. and 2. is that they tend to escalate.<p>Example: &quot;We&#x27;re doing a combo-box component, but to keep it simple let&#x27;s not support multiselect.&quot;<p>Retrofitting such a feature when You Eventually Do Need It(YEDNI?) is neither pleasant nor simple.<p>My take is that one&#x27;s skill level is not the most relevant thing - we have code reviews to deal with exactly this problem.<p>What ultimately matters is whether you&#x27;re adding or subtracting value.<p>I&#x27;ve worked with people who were <i>aggressively incompetent</i>. As in: they had bad ideas and were insistent on implementing them, even going as far as bypassing the regular review cycle.

ALAN (avoid learning anything new) is bad advice if taken literally.<p>Learning fundamental knowledge such as programming paradigms, data structures, algorithms is something that will likely not become obsolete in a year by year basis. You should totally learn this if you have the time.<p>Now, memorizing every API in a framework that is likely going to change in 6 months, is probably not going to be very useful in 5 years (but it can be beneficial to achieve your short-term goals and move your career forward).<p>It&#x27;s not about &quot;avoid learning anything new&quot;, it&#x27;s about being tactical about what to learn.

std::vector everything!! TBH I feel anything beyond a simple array&#x2F;vector&#x2F;stack&#x2F;BST&#x2F;queue is pretty advanced and should only be touched by advanced programmers...

&quot;Programming is rather thankless. You see your works become replaced by superior ones in a year. Unable to run at all in a few more.&quot; ~ why the lucky stiff

This case is making the case for a specialist, it&#x27;s just worded poorly. There&#x27;s a case to be made for such folks, there&#x27;s a case to be made for generalists... and if you&#x27;re super smart with tons of memory you can be a T shaped person. It doesn&#x27;t matter which path you choose, you can thrive in any of them.

I wished he just used the word &#x27;bad&#x27; instead of &#x27;poor&#x27;. I thought this is about cash-strapped programmers.

ALAN might be a good advice, but software is such a miserable place unless you can learn and apply new stuff. My boredom would get me if I would do things the same way every time.<p>UPD: just realized who the author is. He _does_ learn a lot of new things, just not in software development, because it&#x27;s not the focus of his career.

Rather than Avoid Learning Anything New, I&#x27;d say avoid implementing anything new. Options always come in handy, you don&#x27;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

There is no formula to succeed in anything. The more people know something the less it values. It is just random, accept it. Just a tech flavor of random. You can always be a salesman but you can&#x27;t be a good salesman and a good scientist.

I wonder if the author has considered the idea that it&#x27;s not a lack of effort or some inherent cognitive gap that keeps them from being &quot;good&quot; programmers, but perhaps these beliefs instead?

Most of this seems like good advice for all progreammer.<p>Except for the ALAN thing. I think that should be modified with a few qualifications. Don&#x27;t learn anything you will ever use less than 10 times or something.

If &quot;Be aware that most coding advice is bad.&quot; is true, then how confident should I be that this &quot;How to Succeed as a Poor Programmer&quot; coding advice is good? ;)

&gt;&gt;I discuss how to be _an asset to an organization_ when you are not a good programmer.<p>Sounds like it&#x27;s advice on how to sandbox yourself in the interest of the org.

I assumed it was satire

Diligent practice?

Brutally true :)

i love this. this is a <i>good</i> programmer. sure to piss off a lot of people on here who think that because they have big salaries they are good at something.

&gt; 4. Make arrays your goto data structure.<p>The others are arguable. But, in 2019, this is flat out bad advice.<p>Your &quot;go to&quot; 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.<p>But, then, this is hardly surprising advice from someone who only learned about a &quot;scripting language&quot; in 2015. The rest of us realized that those silly &quot;scripting languages&quot; were better than C++ for 90+% of our problems way back in 1995.<p>And anyone who has used a &quot;scripting language&quot; realizes <i>extremely</i> quickly just how stupidly useful hash tables are.