Signs that you're a bad programmer (2012)

One of the unstated, or subliminal purposes of these kinds of ideas is to act as an emotional &quot;vent.&quot; Its social purpose in the programmer community is to present a target for the release of &quot;justified&quot; emotional aggression.<p>Other fields and other kinds of social groups have them in their own contexts.<p>One of the things that such sets of ideas produce, in sufficiently large populations and sufficiently complicated contexts, are <i>false positives</i>. That is to say, you will tend to hastily pattern match your object of justified scorn. You will tend to detect more of them than actually exist. (This is how human beings are wired up.) What&#x27;s more, you will conflate highly salient attributes with actual symptoms of such. Being female, or a member of a certain ethnic group, or being &quot;too old&quot; then becomes a sign of the insidious danger.<p>The thing to remember, is that extraordinary situations require extraordinary causation. Such individuals do exist, but there must be something or someone very powerful propping them up. They could be very good at manipulating people. They could have been granted a sinecure by someone very powerful. Most often, they are the unwitting beneficiaries of pathological organizational policies.<p>So how is a diligent rationalist supposed to approach this? Remember that you are wired up to produce false positives. Be self aware of your social animal instincts that will tend to have you use the subject of your suspicions as an object of scorn. Look diligently for &quot;extraordinary&quot; causation.<p>Most of all, don&#x27;t judge prematurely.

One time, I was helping a friend of mine work on Javascript (js) skills. We cycled through all the basic sorting algorithms to practice js best practices and help with understanding computation complexity issues.<p>On one sorting algorithm, Can&#x27;t remember which one ATM, involved recursion. It was pretty simple. My friend couldn&#x27;t understand the nature of the problem because he didn&#x27;t have a instinctual comprehension of recursion. I threw together a Visio of the process and walked him through the blocks one by one. He still couldn&#x27;t wrap his mind around it. He started to berate himself and I could tell he was giving up on his dream. I told him to keep trying. To keep spending the time on places like HackerRank. He did.<p>8 months later, he landed a job as a js full stack programmer. Not a senior level position, but a damn good one. I&#x27;d seen his work before his interview and it was good. He had a command of all the major frameworks and he was observing all major js design patterns while avoiding idiotic anti-patterns. His code was clean and easy to read.<p>IMO Pointing out that someone APPEARS to code like a loser is a petty playground tactic of someone who has a serious ego issue. Taking someone by the hand and helping them through the hurdles so they can become a better programmer is the solution. I can&#x27;t imagine how my friend would have reacted if he had read this petty article while he was trying so hard to become a decent programmer. He may very well have given up. That&#x27;s not acceptable.<p>There are only people who give up and people who refuse to concede defeat. Ranting on a website about bad programmers is giving up.

I&#x27;m not a big fan of the language used, w.r.t. the dichotomies between a &quot;good&quot; programmer and a &quot;bad&quot; programmer. There are certainly challenges for junior developers that are mentioned in this article (and I agree with most of it), but I wouldn&#x27;t consider those people who do it &quot;bad&quot;, rather &quot;inexperienced&quot;. This may be a mere nuance, but it&#x27;s not something that should be perpetuated. We all have our challenges and we are all learning to do better in our work.<p>In reading this article, I don&#x27;t think any developer purposely does any of these things and if they do, they aren&#x27;t &quot;bad programmers&quot;, but just developers who are still learning.<p>It seems that the intent of the article is good-natured in that it&#x27;s pointing out certain issues with code and how to remedy them, but calling people bad at their craft so that they read the article is a bit strong.

Congratulations on fomenting that impostor syndrome.<p>While the the text contains valid anti-patterns its style is non-helpful. People should not be put down but encouraged. People will notice sooner or later if they are not fit for a field by themselves. The only benefit of berating someone for lack of skills is a temporary catharsis for the one doing the berating while the person at the other end pays a psychological cost of a kind or another unless he&#x27;s really mindful.<p>Berating command-voice is excusable in a heated argument but maintaining this voice throughout a long writing is stylistically a very poor choice, IMO. This just discredits the authors voice as that of an infantile jerk.

In short this article looks at aspects of programming and says if you&#x27;re bad at each aspect you&#x27;re probably bad at the sum of them. I&#x27;m not sure what the purpose is... you can figure out more directly whether you&#x27;re a bad programmer by comparing the code you produce to that of your peers.<p>Aside from that the made up terms are annoying. It would be more readable if he used<p><pre><code> voodoo code =&gt; dead code bulldozer code =&gt; high cohesion subroutines pinball programming =&gt; unreliable code </code></pre> I can&#x27;t think of anything good to say about this article.

&gt; 5. Difficulty seeing through recursion<p>It may be a function of the code I work on but I generally avoid recursion unless I&#x27;m <i>really</i> sure about the bounds of my input, which is rare. Few other things can take a smoothly operating service and hard crash it because the input got just a touch too big. Worse yet, there is usually no warning as the problem approaches.<p>Yea, some languages have tail call optimization, but I&#x27;ve found it to be picky even in languages that have it. i.e. an otherwise innocuous refactoring to a method to make it look a bit cleaner, but logically identical, can all of a sudden crash the process due to TCO not recognizing it anymore. This is also the type of thing that doesn&#x27;t show up in testing, but shows up immediately under production load. Recursion can make some algorithms easier to follow, but I&#x27;ll take a slightly more complicated algorithm over being woken in the middle of the night due to a &#x27;stack level too deep&#x27; exception.

I agree with other&#x27;s statements about not judging prematurely. I feel like every software engineer I have ever run into (including and especially myself) has done some or all of these things at one point or another. We all have bad days, we all have poor judgment sometimes. Giving people the benefit of the doubt in cases of lapsed judgment seems like it would create a far less hostile work environment. If it&#x27;s systemic, it&#x27;s one thing... but let&#x27;s try to avoid a witch hunt mentality. Everyone&#x27;s going to have off days.<p>The only one whose legitimacy as an antipattern I would question however would be this one:<p>&gt;&quot;Bulldozer code&quot; that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)<p>I think it is useful to break up complex logic into discrete methods that represent some logical step in the overall algorithm. If they&#x27;re private methods, I feel like that can add to the readability of the algorithm rather than having it be in one monolithic chunk. I&#x27;ve seen two camps on this - keep it inline vs. make private methods for discrete steps, and I find the latter to be more readable when I look through code (my own or someone else&#x27;s).<p>There is a limit to that, of course. If you end up with a tangled tree of methods, that could work against readability... but even then, if you took that tangled tree and made it a single monolithic method, how often would that actually end up being more readable?

Not sure about the article, since it doesn&#x27;t seem to say anything useful, but one problem I&#x27;m having with beginners is that beginners are extremely superficial in analyzing a problem and extremely superficial in coming up with solutions and have to be told what to do in very precise words and even if you give them a list of things to do, you still have to review their work because they might have missed some of the bullet points.<p>This happens, I believe, primarily due to lack of experience - they haven&#x27;t suffered from superficial understanding of a problem with clients rejecting their solutions, they haven&#x27;t stayed too many times at 2 a.m. fixing production issues, the haven&#x27;t witnessed the proverbial big ball of mud coming to life because of patched up solutions and they haven&#x27;t had a project that had to be rebooted in part because of technical debt created by them. We as humans, only find out that fire burns badly once we get burnt a couple of times.<p>And as a senior I&#x27;m completely out of my league when it comes to educating other people - I&#x27;m totally incapable of compressing 5 or 10 years of experience into a couple of months worth of education. And for example I have initiatives, like lets do presentations on Fridays, lets do code reviews and so on. And we do them for a couple of weeks, but then we observe that nothing changes and that our productivity dropped, because communication represents points of concurrency in the development process and concurrency represents the death of parallelization, which is incompatible with really harsh deadlines. And because these deadlines are a never ending story and the seniors are overwhelmed, management kicks in to &quot;solve the problem&quot; and they start thinking of hiring more people, which really means even more rookies to train, because good people that have the required experience are rare. And the problem to be solved by our project is so complex, that only seniors with a deep understanding of the problem can come up with working solutions for the core pieces, the number of seniors isn&#x27;t growing and these seniors also have to train people and to continuously fix the mistakes that rookies did. It&#x27;s enough to say that it&#x27;s turning into a nightmare.

My list is a lot shorter than this screed. A bad programmer is one who is passionless. No concern over how poor his work is, who doesn&#x27;t want or care to improve.<p>For me, defining a bad programmer is as simple as this.

If anyone hasn&#x27;t read it I highly recommend the book &quot;Antipatterns&quot; (<a href="http://www.amazon.com/AntiPatterns-Refactoring-Software-Architectures-Projects/dp/0471197130=" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;AntiPatterns-Refactoring-Software-Arch...</a><p>... or just google antipatterns.<p>My personal pet peeve is that many programmers don&#x27;t refactor nearly often nor thorougly enough. It should be natural part of the developing process. Especially with large programs you reach certain points where all encompassing refactoring is needed to simplify the code, yet many power through leading to a bloated mess.<p>I&#x27;ve found its not uncommon that even decent complex code can be shrunk 70%-80% using refactoring, code generation and config files.

&gt; <i>&quot;Yo-Yo code&quot; that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)</i><p>I would add: &quot;you designed a language that does these conversions implicitly as part of its evaluation semantics, and thought it was a marvellous idea.&quot;

5.3 is actually <i>not</i> bad code, if it refers to what I think it does. Basically:<p>&quot;Recursive subroutines that concatenate&#x2F;sum to [...] a carry-along output variable&quot;<p>Is an accumulator pattern, which is useful in converting certain types of recursive algorithms into tail recursive algorithms with can be handled much better by most compilers (and unrolled into iteration behind the scenes, which means you get clean recursive code that still won&#x27;t ever run out of stack memory).

signs you&#x27;re too good of a programmer -<p>you use monads in object-oriented languages (like Python)<p>instead of the standard library, you get your algorithms from PDF&#x27;s you have to pay a journal access fee for.<p>you believe in good test coverage: so do the ten thousand people who have downloaded your test suite from github.<p>you leave comments highlighting incorrect behavior... by the standard compiler.<p>you don&#x27;t always formally verify that your program is optimal- sometimes you only formally verify correctness.<p>you&#x27;re a full-stack developer, but wrote some of the layers yourself.<p>investors want to meet the rest of the team

<i>&quot;To get over this deficiency a programmer can practice by using the IDE&#x27;s own debugger as an aide,&quot;</i><p>sign of bad programmer: relying on the IDE?<p><pre><code> &#x27;always have a security professional review the design and implementation.&#x27; </code></pre> At first glance it reads like a list a hypothetical programmer should do, rather than what happens. For a dose of reality, read this article by Joel about the job of the SDETs at MS. [0] I don&#x27;t hold MS as an example of security but Joel paints a picture of serious programmers trying to code then verify commercial software used by millions. [1]<p>Commerce and software demand another set of skills beyond this article. Read the counter-point: &#x27;What Makes a Good Programmer&#x27; <a href="http://www.southsearepublic.org/article/2024/read/what_makes_a_good_programmer/" rel="nofollow">http:&#x2F;&#x2F;www.southsearepublic.org&#x2F;article&#x2F;2024&#x2F;read&#x2F;what_makes...</a><p>ps: Is there a way to prove the output of complex regular expressions?<p>[0] Joel Spolsky, &#x27;Talk at Yale: Part 1 of 3&#x27;, <a href="http://www.joelonsoftware.com/items/2007/12/03.html" rel="nofollow">http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;items&#x2F;2007&#x2F;12&#x2F;03.html</a><p>[1] Then there&#x27;s the open-source way. How many in the OS systems community really have <i>&#x27;security professionals&#x27;</i> review their code? OpenBSD and who else?<p>(various edits)

&gt; 1.4 &quot;Yo-Yo code&quot; that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)<p>An important exception: many abstractions for data passing end up creating exactly this, but are good practice if you can afford them because it means one side of the yo-yo can be changed without breaking the other.

Neither the good programmer nor the bad programmer portrayed here would make a good employee&#x2F;consultant, the former b&#x2F;c things will break while the latter b&#x2F;c things will never get delivered. They say software is eating the world and I believe this is true but not b&#x2F;c genius&#x2F;geek programmers abound but b&#x2F;c there are hordes of smart good-enough &#x27;programmers&#x27; out there putting good enough solutions, and yes, most will not be able to write a recursive function but who cares: the solutions run and solve real problems. That being said, we must thank the gurus who put up the layers that make it posible for the makers to bring out such solutions.

&gt; 5.1 You don&#x27;t use any ergonomic model when designing user interfaces, nor do you have any interest in usability studies<p>Oops - <i>almost guilty</i>. Any suggested reading?

&gt;Incompetence with Regular Expressions<p>Well, method acting here I come!

My take on the opposite - what makes a good programmer: <a href="http://henrikwarne.com/2014/06/30/what-makes-a-good-programmer/" rel="nofollow">http:&#x2F;&#x2F;henrikwarne.com&#x2F;2014&#x2F;06&#x2F;30&#x2F;what-makes-a-good-programm...</a>

These articles always make me feel insecure and for some reason I continue to read them.

<i>6. Distrust of code</i><p>PHP&#x2F;C++&#x2F;Javascript<p><i>4. Dysfunctional sense of causality<p>Symptoms<p>When called on to fix a bug in a deployed program, you try prayer Your debugging repertoire includes rituals like shining your lucky golf ball, twisting your wedding ring, and tapping the nodding-dog toy on your monitor. And when the debugging doesn&#x27;t work, you think it might be because you missed one or didn&#x27;t do them in the right order</i><p>Once again php ...<p>So it seems I am a bad programmer after all.

My definition of a bad programmer is one who does not want to learn and progress. Everything else is just levels of experience.

&gt; Credit card numbers or passwords that are stored in an unsalted hash<p>What&#x27;s the purpose of <i>hashing</i> a credit card number? For passwords, please use a proper KDF instead of reinventing salted password hashing. While it&#x27;s widely known not to build your own crypto, most people still write stuff like sha256(sha256(password) + salt).

A lot of comments here take it on a political level, even if the discussed considerations are (mostly) technical. (I am personally touched by a few points in there and I understand the temptation to go that way myself.) The reasoning behind these &quot;signs&quot; however, is worth its weight in gold and I only hope people will remember and come back to it with cooler heads. Critique (and especially that kind performed on oneself) is almost always necessary in order to get better, even if it hurts. Seeing the objections raised, I was tempted to recommend such kind of critique only if there wouldn&#x27;t be any chance of breaking you, but I can&#x27;t anymore. If you are to fail - fail early, fail often.

&gt; <i>Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in their familiar language&#x27;s style</i><p>Depending what you&#x27;re breaking out of and into, and what your work looks like, this could be idiocy or genius. :)

Previous discussions:<p><a href="https://news.ycombinator.com/item?id=3131439" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3131439</a><p><a href="https://news.ycombinator.com/item?id=746873" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=746873</a>

Working with HTML&#x2F;CSS has made me feel like I&#x27;ve got a Chronically poor knowledge of the platform&#x27;s features. In 6 years I&#x27;ve not been able to form a coherent mental model of how it works that lets me actually go &quot;oh, I need to do Foo? I&#x27;ll just do Bar and Baz.&quot;<p>Is this a sign that I should stick to working with scheme, Python, Go, JS and other actually Turing-complete tools and my mind isn&#x27;t made for layout languages? (I have the same problem with Tex.) Or is there something I can read that will finally help this make sense? Or do I just need another 4 years?

&quot;Using whatever syntax is necessary to break out of the model, then writing the remainder of the program in their familiar language&#x27;s style&quot;<p>This one really rang home with me, having previously dealt with developers who worked in both .Net and PHP with frameworks that handled models very differently.

What&#x27;s up with 5.5?<p>&gt;Your program produces output to be read by another (eg: a browser)<p>This is a problem?

There&#x27;s a difference between being a bad programmer and bad programming.

<i>Inability to comprehend pointers</i><p><i>Inability to determine the order of program execution</i><p>I don&#x27;t think that pointers or mutable variables are important, when you are a pure functional or logic programmer.

I&#x27;m just nitpicking here, but<p>&gt; Recursive functions that don&#x27;t test for a base condition<p>Base conditions are not necessary in lazy languages.<p>Example in Haskell:<p><pre><code> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)</code></pre>

The author of this piece should not fret. Soon enough computers will program themselves, and they will be vastly superior in this task to their human counterparts. Perhaps then the author will bask in the glory of programming perfection while waiting to be processed in the unemployment line.<p>Seriously, get over yourself. If the programmers you hire fail at their task, blame your lack of leadership, mentor ship, or hiring skills. They can&#x27;t all be the A-team, can they? Learn to win with the B-team.

What does homebrew &quot;business rule engines&quot; mean? Are there a bunch of them already made? What would be an example of this?

Call me overly sure of myself, but it is painful reading this since I can relate a lot of it to my co-workers.

A bad programmer is one that has worked for many years in the field and fails to help those less experienced.

Still fun to read. Could anyone shed some light on author&#x27;s background that led to this piece?

(eg: calling the save() function multiple times &quot;just to be sure&quot;)<p>Who else does this for apps with a UI?

Bonus points for including remedies.

Symptom: fears that the AI will (in the near future) be writing programs for us, so why bother...<p>Remedy: ?

Ok, time to give up my career. I just realized that I&#x27;m a useless programmer.

Surprisingly good. I got a good chuckle recognizing myself in some of these.

<i>&gt;&gt;4. Inability to comprehend pointers</i><p>I love C, it&#x27;s my favorite language.... but there is no way that pointers are important enough that not knowing them == bad programmer. There are plenty of good developers who&#x27;ve never even had to deal with pointers, even in 2012.

These posts are ironic.

Fantastic!

yup...and this is why I stopped. because of this kind of tone that I found toxic in actual job settings but then again it&#x27;s points are fairly valid to filter only the strongest programmers.<p>Tell engineers to come up with their expected salary in a room and they will fight and compete with each other to work for free. The rationale ones, or the &#x27;bad&#x27; engineers seemingly walk out because they still have the sanity intact.<p>Interestingly enough, companies and employers know this about engineers, and would be more than happy to screw you over what you actually deserve. All they have to do is sit aside and watch the professionals sabatoge each other. They are the perfect employee. Fire them once they build the pyramid, and find slaves overseas to maintain it.<p>This is what I realized at the end of the day. All I care is that I turning ideas into real products that work. If these are product that I can sell on my own, even better. If my skill and experience allows me to do this over and over, then it is good enough of a skill for me. Might not be a 10x engineer but neither do I want to be involved in a gladiator matches anytime we have to build something but end up arguing over irrelevant things, and end up delivering late.

&gt;<i>&quot;Bulldozer code&quot; that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)</i><p>&gt;<i>3. Difficulty writing functions with low cohesion</i><p>Is there some definition of cohesion I don&#x27;t know, or is the author confusing cohesion and coupling?

Point number 9: &quot;using HN for programming advice or guidance&quot; - relying on HN with it&#x27;s fixation on the latest shiny (are we still hyping Go and React today?) and it&#x27;s endless pursuit of academically useless tools (big shout to Haskell, any meta language built upon yet another interpreted and JITd language).

&gt; <i>Using cut-n-paste code from someone else&#x27;s program to deal with I&#x2F;O and Monads</i><p>&gt; <i>Failure to implement a linked list, or write code that inserts&#x2F;deletes nodes from linked list or tree without losing data</i><p>&gt; <i>Difficulty seeing through recursion</i><p>I would argue that using monads, implementing your own linked list or using recursion is sign of bad programming... But I am just Java cowboy, so thanks for the enlightenment!