10 ms·

How to Succeed as a Poor Programmer

184 points by Impossible 7y ago

robbya 7y ago
Two things jump out to me: > Only learn something new when forced I think there is a balance between always doing things in a new way, versus always doing things as you'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't going to grow. > Avoid linking to other software unless forced. It empirically rarely goes well. Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. 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 'good' programers may overlook
- deleted 7y ago
  [deleted]
- mysterydip 7y ago
  > Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. Probably referring to the dependency hell that can occur. Things work great when you first choose your libraries, but then months or years later while maintaining code you find x feature is deprecated or lib y no longer plays nicely with lib z or lib a is dependent on lib b version 2 and lib c needs lib b to be version 3, etc.
- zitterbewegung 7y ago
  I think I interpret "Only learn something new when forced" is more like you should prioritize what to learn to do a task. Learning new things to learn new things is different than having a concrete project that emphasizes that you should learn one new thing. Learning the newest system of the week isn't really going to help you as much as a tried and true system that is well maintained and proven to work. The second part about linking to other software is valid. What if the thing you are linking to is not going to be maintained? What if the thing you are linking to has a security issue? Now you are probably going to have to either link to something else or replicate the functionality. By only linking to things that are essentially hard to replicate instead of blindly linking to anything else. In the above examples it is more of striking a balance instead of mere absolutes.
- k__ 7y ago
  I used PHP where everyone would reinvent the wheel and JS where everyone would install hundreds of packages. This gave me the feeling that the truth is somewhere in-between. Maybe NPM packages are overall low quality and it would be okay to use more of them if they were better, but I'm now just installing a package when I don't have the time or skills to code it myself. This saved me from dependency hell, but it also helped me to move faster than doing all on my own.
  - baroffoos 7y ago
    I feel like rails is the good in between. It contains loads of helpful functions and tools to get 90% of the stuff you need done but its all part of one package so its all tested together and comes from one trusted org rather than 1000 random js devs.
- BigJono 7y ago
  Learning is pretty simple, the golden rule is "Don't learn new tech, learn how to solve new problems". Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. A better example might be something like Postgres and DynamoDB, since it can go either way. If your problem is 'I need a database for a CRUD app' then learning the second one is stupid because they both solve that problem just fine. But if your problem is 'I have a complex use case, my data is in a bad format for the one I'm using and I'm taking a huge hit in performance' then learning the other one is a reasonable choice and probably not a waste of time. Basically whenever you take the time to learn something, make sure you're getting something out of it in terms of end results. It feels good to just learn more of the same tech, and if the API is different enough it'll feel like you're making progress, but you're probably not.
  - soulofmischief 7y ago
    > Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. Settling on Mithril as my front-end library was a long journey from framework to framework. If I had stopped at Vue or React, I'd be much worse off for it. Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Sometimes you need to move on, and if later asked about your technical choices in a professional environment, you need to have a professional answer that comes from wide experience.
    - BigJono 7y ago
      > Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Well, I did specifically give an example of two techs that do similar things that might be worth learning if they're different enough that one solves a problem the other doesn't. I don't know anything about Mithril, but if you're right that you'd be 'much worse off' then that would be a similar case, no?
albertoCaroM 7y ago
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.
- anon91831837 7y ago
  Yes, it's a terrible, second-stringer attitude. Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass. TBH, if someone's only in it for the money, they're wasting their life in the wrong field when they could be doing something else such that their morale and satisfaction would be greater.
  - cge42 7y ago
    Ahh yes, I'll be sure to let consults notes Distinguished Scientist at NVIDIA and adjunct professor at the University of Utah Peter Shirley that he's a second-stringer and not nearly "badass" enough for Hacker News commentator anon91831837 and he's wasting his life in the wrong field.
    - diminoten 7y ago
      It's actually sad, his credentials suggest he's capable of a much better post than this...
      - michrassena 7y ago
        Either the post is intended sarcastically, or there's something to learn from it.
    - throwaway0990 7y ago
      It is not like distinguished scientist credentials necessarily correlate with exceptional code quality or software development practices. And it is not like NVIDIA is particularly known to be a place that excels at such.
anaphor 7y ago
I don't think most of this applies only to "poor programmers". The advice about KISS is something many "good" programmers would benefit from following. Likewise, I've seen good programmers recommend using arrays as your first attempt at a data structure as well (e.g. Jonathan Blow, https://www.youtube.com/watch?v=JjDsP5n2kSM https://www.youtube.com/watch?v=JjDsP5n2kSM )
gigatexal 7y ago
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. So I’m working on getting better and getting more confident.
- her_tummy_hurts 7y ago
  You could make a career out of just SQL. I know my company could use a decent SQL programmer. We’ve got hundreds and hundreds of procs written by SQL amateurs
  - gigatexal 7y ago
    That’d be a lot of fun. I find so much joy in that actually. Figuring out what variation of a query satisfies the query planner to create the most performant plans is fun!
  - denton-scratch 7y ago
    Correct. Tuning SQL queries can deliver performance improvements of several thousand percent, in exchange for just a few hours' work. EXPLAIN is your friend.
- northwest65 7y ago
  >I’m having an existential crisis Don't. There are so many poorly performing queries and databases in the world that you could make a very tidy income just specializing in sorting that out. Even if you knew nothing else that skill will keep you employable for decades to come.
  - seppin 7y ago
    Or more to the point, don't define yourself by your work.
- pnako 7y ago
  It's easy to pick up anything. It's difficult to master most. If you're good at SQL, why not transition to be a full-time DBA? In the right companies, good DBAs are highly valued. I suspect there is quite some business helping companies wanting to transition from Oracle or MongoDB to PostgreSQL.
29athrowaway 7y ago
ALAN (avoid learning anything new) is bad advice if taken literally. 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. 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). It's not about "avoid learning anything new", it's about being tactical about what to learn.
the_cat_kittles 7y ago
i love this. this is a good programmer. sure to piss off a lot of people on here who think that because they have big salaries they are good at something.
jugg1es 7y ago
This is such a bizarre post. If you have the self-awareness to admit this about yourself, you are probably not a poor programmer. 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. Most importantly - poor programmers do not learn from their mistakes and are unable to see that they are poor programmers.
- RadiantSecurity 7y ago
  > 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. All of these examples make sense in the context of your business, but in some environments these might be best practice ;)
  - nwah1 7y ago
    There's different levels of concern for a public API and an internal interface. If you control all publishers and subscribers, then you don't need to worry quite as much about sanity checking inputs or making every possible workable input produce a valid result.
  - foo101 7y ago
    > but in some environments these might be best practice What are those environments? Can you be more specific?
    - macintux 7y ago
      I don’t know what they had in mind, but certainly Erlang encourages those sorts of approaches.
    - RadiantSecurity 7y ago
      There are plenty of environments where deviating from spec (even when fixing an apparently trivial bug) would not be ok without assessing the situation for potential unintended behaviors. High-risk systems where a software bug could result in loss of life - aviation, submarine tech, defense, medical etc. Edit: This is for throwing exceptions on undefined behavior. For unlimited threads I imagine scenarios exist particularly when scalable computing is so popular. Large high traffic web stores such as Amazon/Ebay, financial institutions, etc. Either way, the problem shouldn't be solved by an individual developer on a project making things up as they go - its a problem that probably needs to be defined at a framework layer, and discussed within the team of developers and requirements definers.
alephnan 7y ago
> Finally, let the computer do the work; Dave Kirk talks about the elegance of brute force (I don't know if it original with him). This is a cousin of KISS. Hardware is fast. Software is hard. Yeah, I don’t know. The cloud bill is going to be expensive.
- aurelwu 7y ago
  It is also terrible advice in regards to Energy consumption
deleted 7y ago
[deleted]
BrissyCoder 7y ago
Most of this seems like good advice for all progreammer. Except for the ALAN thing. I think that should be modified with a few qualifications. Don't learn anything you will ever use less than 10 times or something.
denton-scratch 7y ago
I totally agree with this stuff. I was a professional programmer (now retired), and not a very good one. I'm familiar with Dunning-Kruger; I've worked with good programmers and bad ones, and I can tell the difference. Very good programmers are far and few. 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. I recommend retiring from programming. You don't have to keep up with the young whippersnappers any more, you can carry on coding in bash, you don'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. Or give it up completely, and learn cooking, or drumming, or interior-decorating. 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. 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't shine. JS is a very clever language; but cleverness isn't always best.
- glloydell 7y ago
  > you can stuff Node and that ridiculous dependency system where the sun don't shine. You're really taking embedded computing to the next level
Noumenon72 7y ago
> If you are bad at programming, you are still programming, something that very few people can do. That's heartening. I bet a very bad doctor or lawyer can still do some good somewhere too, as long as they don't convince themselves they are better than they are.
michannne 7y ago
Rather than Avoid Learning Anything New, I'd say avoid implementing anything new. Options always come in handy, you don'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
viburnum 7y ago
Kids, trust your elders on this one, the author is correct.
rukuu001 7y ago
I assumed it was satire
markus_zhang 7y ago
std::vector everything!! TBH I feel anything beyond a simple array/vector/stack/BST/queue is pretty advanced and should only be touched by advanced programmers...
deleted 7y ago
[deleted]
benboughton1 7y ago
I think the best way to make it as a 'poor programmer' is be a domain specific 'poor programmer'. I am bad a nearly all my programming in all my projects but probably just as efficient at getting jobs done than a 'good programmer' 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.
deleted 7y ago
[deleted]
bsder 7y ago
> 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 is enormous. But, then, this is hardly surprising advice from someone who only learned about a "scripting language" in 2015. The rest of us realized that those silly "scripting languages" were better than C++ for 90+% of our problems way back in 1995. And anyone who has used a "scripting language" realizes extremely quickly just how stupidly useful hash tables are.
- AnimalMuppet 7y ago
  > Your "go to" data structures should be hash tables about 70% of the time and vectors about 30% of the time. Depends on your program. In my world, it's vectors about 99% of the time when it's not a fixed-size array.
- banachtarski 7y ago
  > 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.
  - bsder 7y ago
    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.
    - banachtarski 7y ago
      We're just in different fields. The OP of the post was a graphics engineer, as am I. We drink to celebrate when we shave off a millisecond haha.
codr7 7y ago
Diligent practice?
gabrielblack 7y ago
> 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 always the same: a day they wake-up realizing that the "product" 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't skilled to port the code base to modern standards/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.
- ensiferum 7y ago
  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++40" standard doesn't obsolete old code or turn it "crap".
  - daemin 7y ago
    The best thing about seeing the codebase for a long lived product is seeing the layers of when something was written by the types of patterns found in the code.
  - gabrielblack 7y ago
    The age make it "crap", but not in the way you think. I can speak about C++. C++ code wrote in the older standard, let say C++ pre-11, who are 20 or more years old make it difficult to maintain because new generation of programmers are not generally interested to legacy code or in learning old c++ standards and skilled programmers don't want be relegated to be eternally maintainer of old projects. For this reason projects die by asphyxia. We have that good code base in Cobol, ok, but the point is: who cares ? Who is important when you need new programmers. Besides, a part considerations on the language, the architecture is important we live in a world of microservices and old code not updated to modern paradigms could became "crap", even if if the most elegant code.
sixtypoundhound 7y ago
This is probably really bad but I totally empathize (and agree?) KISS => everyone should do this YAGNI => 95% of the shit I add is ignored (and I've got fairly objective proof that I can develop good projects) ALAN => Master SQL, one scripting language, and how to use Stack Overflow. You'll be the most useful dev on the team. I agree with most of the rest. Bonus point: never be afraid to tell a business person that what they want is an exceptionally bad idea. it usually is.
overgard 7y ago
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, insights on relationships, new concepts that apply to old things, etc. If this guy thinks learning is such a burden, it's probably because he refuses to learn anything in the first place. If he thinks he's a poor programmer, it probably has less to do with innate ability and 100% to do with the attitudes he gives as "advice" in this blog.
- aledalgrande 7y ago
  Agree. Everyone is a poor programmer when they start. If they all thought like this, we would have zero good programmers.
- geowwy 7y ago
  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 into mastering SQL or Unix will probably continue benefiting me for the rest of my career. Even C will continue to benefit me, even though it'll only ever be a small part of my job. So I would modify his rule: Avoid Learning Anything New – Learn Something Old
  - 01100011 7y ago
    I agree about 90%. Sometimes though, it pays to learn the weird or new stuff. Sometimes, you can make a lot of money knowing the next big thing, even if it goes away in a year. You have to be well positioned though, like being an hourly contractor. I'm generally the guy who knows the boring shit. C, networking, 'Linux', hardware, RF... But I keep telling myself I'm going to jump on the next bandwagon just to see how the ride goes.
human20190310 7y ago
It's a great, succinct post. Deeply 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. Moreover, I trust the advice of someone who rates themselves poorly more than someone proclaiming that they're a hotshot.
noonespecial 7y ago
If you ALAN you can't KISS. You won't know what the simplest thing is. You'll end up with miles of nested "ifs" instead of 4 lines of recursion. A gazillion "else ifs" instead of case etc. He's got one thing right. He's a poor programmer. "Success" must be mighty loosely defined here.
manmal 7y ago
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.
KirinDave 7y ago
I wonder if the author has considered the idea that it's not a lack of effort or some inherent cognitive gap that keeps them from being "good" programmers, but perhaps these beliefs instead?
- noughtme 7y ago
  I think it’s time. Peter Shirley decided to specialize in computer graphics, leaving the programming to people who would implement his ideas in libraries, and the production developers who use those libraries.
  - seanmcdirmid 7y ago
    I didn’t realize this was Pete Shirley’s blog. Isn’t he still a professor?
  - KirinDave 7y ago
    Interesting, but does that change anything though? I had a famous cryptographer professor. He refused to learn anything past Pascal. He freely admitted he was no longer a programmer and that he shouldn't be doing it. That seems like a different message from the messages presented here.
aledalgrande 7y ago
I dislike this mindset too. For any other profession it would be crazy, but for programming it'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?
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
oneepic 7y ago
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't necessarily conflict with each other; every piece of advice can apply or not, depending on the circumstances. On a larger scale, it's remarkable that a lot of the general programming advice given today is more of a heuristic/guide than a tautology, but many people still assert that their advice is The One Right Way To Do Things. It's important to understand that the vast majority of all this advice comes from real examples of what worked and what didn't. So, perhaps the best thing one can do as a programmer, in any domain, with any technology, whether you're a great programmer or a poor programmer, is to listen to it all with zen and a grain of salt.
known 7y ago
Brutally true :)
rdiddly 7y ago
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 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're gonna need a goddamned shitty index. A whole 'nuther variable! Get some generics ya dufus!
- Tade0 7y ago
  Former monetarily poor[0] programmer here. AMA [0] $7k per annum take-home-pay.
rr-geil-j 7y ago
I wished he just used the word 'bad' instead of 'poor'. I thought this is about cash-strapped programmers.
em3rgent0rdr 7y ago
If "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? ;)
- djmips 7y ago
  Yes.
blue_devil 7y ago
>>I discuss how to be _an asset to an organization_ when you are not a good programmer. Sounds like it's advice on how to sandbox yourself in the interest of the org.
oytis 7y ago
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. UPD: just realized who the author is. He _does_ learn a lot of new things, just not in software development, because it's not the focus of his career.
dagw 7y ago
With regards to "Avoid Learning Anything New" 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't get to be senior researchers at Nvidia or have the following publication list: https://scholar.google.com/citations?hl=en&user=nHx9IgYAAAAJ&view_op=list_works&sortby=pubdate https://scholar.google.com/citations?hl=en&user=nHx9IgYAAAAJ... 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.
Tade0 7y ago
One problem I have with 1. and 2. is that they tend to escalate. 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.
wyclif 7y ago
"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." ~ why the lucky stiff
mutant_rvalue2 7y ago
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't be a good salesman and a good scientist.
kissgyorgy 7y ago
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't do these, don't like to think or solve problems, you will stay indeed poor.
segmondy 7y ago
This case is making the case for a specialist, it's just worded poorly. There's a case to be made for such folks, there's a case to be made for generalists... and if you're super smart with tons of memory you can be a T shaped person. It doesn't matter which path you choose, you can thrive in any of them.

184 points by Impossible 7y ago

Two things jump out to me: > Only learn something new when forced I think there is a balance between always doing things in a new way, versus always doing things as you'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't going to grow. > Avoid linking to other software unless forced. It empirically rarely goes well. Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. 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 'good' programers may overlook

deleted 7y ago
[deleted]
mysterydip 7y ago
> Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. Probably referring to the dependency hell that can occur. Things work great when you first choose your libraries, but then months or years later while maintaining code you find x feature is deprecated or lib y no longer plays nicely with lib z or lib a is dependent on lib b version 2 and lib c needs lib b to be version 3, etc.
zitterbewegung 7y ago
I think I interpret "Only learn something new when forced" is more like you should prioritize what to learn to do a task. Learning new things to learn new things is different than having a concrete project that emphasizes that you should learn one new thing. Learning the newest system of the week isn't really going to help you as much as a tried and true system that is well maintained and proven to work. The second part about linking to other software is valid. What if the thing you are linking to is not going to be maintained? What if the thing you are linking to has a security issue? Now you are probably going to have to either link to something else or replicate the functionality. By only linking to things that are essentially hard to replicate instead of blindly linking to anything else. In the above examples it is more of striking a balance instead of mere absolutes.
k__ 7y ago
I used PHP where everyone would reinvent the wheel and JS where everyone would install hundreds of packages. This gave me the feeling that the truth is somewhere in-between. Maybe NPM packages are overall low quality and it would be okay to use more of them if they were better, but I'm now just installing a package when I don't have the time or skills to code it myself. This saved me from dependency hell, but it also helped me to move faster than doing all on my own.
- baroffoos 7y ago
  I feel like rails is the good in between. It contains loads of helpful functions and tools to get 90% of the stuff you need done but its all part of one package so its all tested together and comes from one trusted org rather than 1000 random js devs.
BigJono 7y ago
Learning is pretty simple, the golden rule is "Don't learn new tech, learn how to solve new problems". Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. A better example might be something like Postgres and DynamoDB, since it can go either way. If your problem is 'I need a database for a CRUD app' then learning the second one is stupid because they both solve that problem just fine. But if your problem is 'I have a complex use case, my data is in a bad format for the one I'm using and I'm taking a huge hit in performance' then learning the other one is a reasonable choice and probably not a waste of time. Basically whenever you take the time to learn something, make sure you're getting something out of it in terms of end results. It feels good to just learn more of the same tech, and if the API is different enough it'll feel like you're making progress, but you're probably not.
- soulofmischief 7y ago
  > Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. Settling on Mithril as my front-end library was a long journey from framework to framework. If I had stopped at Vue or React, I'd be much worse off for it. Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Sometimes you need to move on, and if later asked about your technical choices in a professional environment, you need to have a professional answer that comes from wide experience.
  - BigJono 7y ago
    > Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Well, I did specifically give an example of two techs that do similar things that might be worth learning if they're different enough that one solves a problem the other doesn't. I don't know anything about Mithril, but if you're right that you'd be 'much worse off' then that would be a similar case, no?

albertoCaroM 7y ago

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.

anon91831837 7y ago
Yes, it's a terrible, second-stringer attitude. Curiosity and obsession are a couple of the key differentiators between a workaday jobber in it for the money (like many who flocked to tech in the dot-com times) and a badass. TBH, if someone's only in it for the money, they're wasting their life in the wrong field when they could be doing something else such that their morale and satisfaction would be greater.
- cge42 7y ago
  Ahh yes, I'll be sure to let consults notes Distinguished Scientist at NVIDIA and adjunct professor at the University of Utah Peter Shirley that he's a second-stringer and not nearly "badass" enough for Hacker News commentator anon91831837 and he's wasting his life in the wrong field.
  - diminoten 7y ago
    It's actually sad, his credentials suggest he's capable of a much better post than this...
    - michrassena 7y ago
      Either the post is intended sarcastically, or there's something to learn from it.
  - throwaway0990 7y ago
    It is not like distinguished scientist credentials necessarily correlate with exceptional code quality or software development practices. And it is not like NVIDIA is particularly known to be a place that excels at such.

anaphor 7y ago

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

gigatexal 7y ago

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

her_tummy_hurts 7y ago
You could make a career out of just SQL. I know my company could use a decent SQL programmer. We’ve got hundreds and hundreds of procs written by SQL amateurs
- gigatexal 7y ago
  That’d be a lot of fun. I find so much joy in that actually. Figuring out what variation of a query satisfies the query planner to create the most performant plans is fun!
- denton-scratch 7y ago
  Correct. Tuning SQL queries can deliver performance improvements of several thousand percent, in exchange for just a few hours' work. EXPLAIN is your friend.
northwest65 7y ago
>I’m having an existential crisis Don't. There are so many poorly performing queries and databases in the world that you could make a very tidy income just specializing in sorting that out. Even if you knew nothing else that skill will keep you employable for decades to come.
- seppin 7y ago
  Or more to the point, don't define yourself by your work.
pnako 7y ago
It's easy to pick up anything. It's difficult to master most. If you're good at SQL, why not transition to be a full-time DBA? In the right companies, good DBAs are highly valued. I suspect there is quite some business helping companies wanting to transition from Oracle or MongoDB to PostgreSQL.

29athrowaway 7y ago

ALAN (avoid learning anything new) is bad advice if taken literally. 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. 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). It's not about "avoid learning anything new", it's about being tactical about what to learn.

the_cat_kittles 7y ago

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

jugg1es 7y ago

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

RadiantSecurity 7y ago
> 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. All of these examples make sense in the context of your business, but in some environments these might be best practice ;)
- nwah1 7y ago
  There's different levels of concern for a public API and an internal interface. If you control all publishers and subscribers, then you don't need to worry quite as much about sanity checking inputs or making every possible workable input produce a valid result.
- foo101 7y ago
  > but in some environments these might be best practice What are those environments? Can you be more specific?
  - macintux 7y ago
    I don’t know what they had in mind, but certainly Erlang encourages those sorts of approaches.
  - RadiantSecurity 7y ago
    There are plenty of environments where deviating from spec (even when fixing an apparently trivial bug) would not be ok without assessing the situation for potential unintended behaviors. High-risk systems where a software bug could result in loss of life - aviation, submarine tech, defense, medical etc. Edit: This is for throwing exceptions on undefined behavior. For unlimited threads I imagine scenarios exist particularly when scalable computing is so popular. Large high traffic web stores such as Amazon/Ebay, financial institutions, etc. Either way, the problem shouldn't be solved by an individual developer on a project making things up as they go - its a problem that probably needs to be defined at a framework layer, and discussed within the team of developers and requirements definers.

alephnan 7y ago

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

aurelwu 7y ago
It is also terrible advice in regards to Energy consumption

deleted 7y ago

[deleted]

BrissyCoder 7y ago

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

denton-scratch 7y ago

I totally agree with this stuff. I was a professional programmer (now retired), and not a very good one. I'm familiar with Dunning-Kruger; I've worked with good programmers and bad ones, and I can tell the difference. Very good programmers are far and few. 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. I recommend retiring from programming. You don't have to keep up with the young whippersnappers any more, you can carry on coding in bash, you don'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. Or give it up completely, and learn cooking, or drumming, or interior-decorating. 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. 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't shine. JS is a very clever language; but cleverness isn't always best.

glloydell 7y ago
> you can stuff Node and that ridiculous dependency system where the sun don't shine. You're really taking embedded computing to the next level

Noumenon72 7y ago

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

michannne 7y ago

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

viburnum 7y ago

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

rukuu001 7y ago

I assumed it was satire

markus_zhang 7y ago

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

deleted 7y ago

[deleted]

benboughton1 7y ago

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

deleted 7y ago

[deleted]

bsder 7y ago

> 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 is enormous. But, then, this is hardly surprising advice from someone who only learned about a "scripting language" in 2015. The rest of us realized that those silly "scripting languages" were better than C++ for 90+% of our problems way back in 1995. And anyone who has used a "scripting language" realizes extremely quickly just how stupidly useful hash tables are.

AnimalMuppet 7y ago
> Your "go to" data structures should be hash tables about 70% of the time and vectors about 30% of the time. Depends on your program. In my world, it's vectors about 99% of the time when it's not a fixed-size array.
banachtarski 7y ago
> 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.
- bsder 7y ago
  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.
  - banachtarski 7y ago
    We're just in different fields. The OP of the post was a graphics engineer, as am I. We drink to celebrate when we shave off a millisecond haha.

codr7 7y ago

Diligent practice?

gabrielblack 7y ago

> 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 always the same: a day they wake-up realizing that the "product" 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't skilled to port the code base to modern standards/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.

ensiferum 7y ago
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++40" standard doesn't obsolete old code or turn it "crap".
- daemin 7y ago
  The best thing about seeing the codebase for a long lived product is seeing the layers of when something was written by the types of patterns found in the code.
- gabrielblack 7y ago
  The age make it "crap", but not in the way you think. I can speak about C++. C++ code wrote in the older standard, let say C++ pre-11, who are 20 or more years old make it difficult to maintain because new generation of programmers are not generally interested to legacy code or in learning old c++ standards and skilled programmers don't want be relegated to be eternally maintainer of old projects. For this reason projects die by asphyxia. We have that good code base in Cobol, ok, but the point is: who cares ? Who is important when you need new programmers. Besides, a part considerations on the language, the architecture is important we live in a world of microservices and old code not updated to modern paradigms could became "crap", even if if the most elegant code.

sixtypoundhound 7y ago

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

overgard 7y ago

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, insights on relationships, new concepts that apply to old things, etc. If this guy thinks learning is such a burden, it's probably because he refuses to learn anything in the first place. If he thinks he's a poor programmer, it probably has less to do with innate ability and 100% to do with the attitudes he gives as "advice" in this blog.

aledalgrande 7y ago
Agree. Everyone is a poor programmer when they start. If they all thought like this, we would have zero good programmers.
geowwy 7y ago
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 into mastering SQL or Unix will probably continue benefiting me for the rest of my career. Even C will continue to benefit me, even though it'll only ever be a small part of my job. So I would modify his rule: Avoid Learning Anything New – Learn Something Old
- 01100011 7y ago
  I agree about 90%. Sometimes though, it pays to learn the weird or new stuff. Sometimes, you can make a lot of money knowing the next big thing, even if it goes away in a year. You have to be well positioned though, like being an hourly contractor. I'm generally the guy who knows the boring shit. C, networking, 'Linux', hardware, RF... But I keep telling myself I'm going to jump on the next bandwagon just to see how the ride goes.

human20190310 7y ago

It's a great, succinct post. Deeply 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. Moreover, I trust the advice of someone who rates themselves poorly more than someone proclaiming that they're a hotshot.

noonespecial 7y ago

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

manmal 7y ago

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.

KirinDave 7y ago

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

noughtme 7y ago
I think it’s time. Peter Shirley decided to specialize in computer graphics, leaving the programming to people who would implement his ideas in libraries, and the production developers who use those libraries.
- seanmcdirmid 7y ago
  I didn’t realize this was Pete Shirley’s blog. Isn’t he still a professor?
- KirinDave 7y ago
  Interesting, but does that change anything though? I had a famous cryptographer professor. He refused to learn anything past Pascal. He freely admitted he was no longer a programmer and that he shouldn't be doing it. That seems like a different message from the messages presented here.

aledalgrande 7y ago

I dislike this mindset too. For any other profession it would be crazy, but for programming it'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?

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

oneepic 7y ago

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't necessarily conflict with each other; every piece of advice can apply or not, depending on the circumstances. On a larger scale, it's remarkable that a lot of the general programming advice given today is more of a heuristic/guide than a tautology, but many people still assert that their advice is The One Right Way To Do Things. It's important to understand that the vast majority of all this advice comes from real examples of what worked and what didn't. So, perhaps the best thing one can do as a programmer, in any domain, with any technology, whether you're a great programmer or a poor programmer, is to listen to it all with zen and a grain of salt.

known 7y ago

Brutally true :)

rdiddly 7y ago

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 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're gonna need a goddamned shitty index. A whole 'nuther variable! Get some generics ya dufus!

Tade0 7y ago
Former monetarily poor[0] programmer here. AMA [0] $7k per annum take-home-pay.

rr-geil-j 7y ago

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

em3rgent0rdr 7y ago

If "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? ;)

djmips 7y ago
Yes.

blue_devil 7y ago

>>I discuss how to be _an asset to an organization_ when you are not a good programmer. Sounds like it's advice on how to sandbox yourself in the interest of the org.

oytis 7y ago

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. UPD: just realized who the author is. He _does_ learn a lot of new things, just not in software development, because it's not the focus of his career.

dagw 7y ago

With regards to "Avoid Learning Anything New" 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't get to be senior researchers at Nvidia or have the following publication list: https://scholar.google.com/citations?hl=en&user=nHx9IgYAAAAJ&view_op=list_works&sortby=pubdate https://scholar.google.com/citations?hl=en&user=nHx9IgYAAAAJ... 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.

Tade0 7y ago

One problem I have with 1. and 2. is that they tend to escalate. 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.

wyclif 7y ago

"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." ~ why the lucky stiff

mutant_rvalue2 7y ago

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't be a good salesman and a good scientist.

kissgyorgy 7y ago

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't do these, don't like to think or solve problems, you will stay indeed poor.

segmondy 7y ago

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