Don’t Believe Anyone Who Tells You Learning To Code Is Easy

Just because you taught some 3rd graders a for loop doesn't make them coders and it certainly doesn't make them engineers.

The programming is easy myth is doubly bad: it sets a false expectation for the aspirants and belittles actual engineers' lifetimes of study.

My first job was doing Perl, after studying Java. The Perl cookbook was a godsend, and basically encouraged copy pasting BUT had a discussion on the different methods presented and advantages of each one. I personally found that a very good way to learn.

This is one thing I find nice in the Perl community. I haven't used Perl for a few years now, but I always found PeelMonks a lot better then Stack Overflow, because it encourages the discussions that Stack Overflow discourages. Essentially it encourages the bad type of copy pasting I have described.

I see lots of bioinformaticians writing simple scripts usually just counting stuff up, and doing some stats. It needs to run once, on one machine and often only on one dataset.

That type of programming is easy.

I am working for a sequencing centre, doing the database to run the place. I inherited a self taught bioinformaticians code after she had left. Second worst code I have ever seen (the worst was also a self taught bioinformatician, who didn't even indent stuff). The code was so bad, I had to refactor it just to debug it. The team leader didn't see a problem. It had worked. He didn't see the fact that it would have taken me a day or two to write this from scratch, if I had had an original specification, rather than spending a week to refactor her code until it worked. To this day, I have no idea what parts of the code are doing (I can see it is reading byte 8 of a binary file and doing something. I have no idea what the contents of that file are). At least now I have made the code modular so I can see the output of reading the file into a huge nested dictionary.

Learning to code is easy. Learning to code well is not. Hell we can't even decide what coding "well" means. 100% test coverage? Shit that works? Something that is readable and maintainable? Something that runs faster than all the equivalent software? In the end I think experience will mean a developer can work out which of these is most important. Maybe just getting something that works is what is important, and the example I gave above is perfectly acceptable code.

That larger vocabulary you sneer at is much of what allows developers to be multiplicatively productive, allows them to do much more work and do it in a faster and less error-prone way.

Or, put another way: are they having to maintain your code when you get tired of it and move on or are they having to deal with second-order effects from your code being more brittle, less flexible, and slower to work on? 'Cause if so, they're not the asshat.