15 noob mistakes even experienced developers still make

Source:- infoworld.com

Coders are gonna code and newbies are gonna noob. Sometimes, even experienced coders make newbie mistakes. In the 20-plus years I’ve been at it, I’ve seen it all. But mostly I’ve seen the same mistakes over and over again.

These common mistakes are of the tactical variety. You should also do good hygiene like use revision control, but even if you do good hygiene you may be making these other tactical mistakes, and suffering as a result.

Noob mistake 1: Use Make or Shell as a build tool

If you’re not writing C or C++, Make is probably not your friend. Make launches another compiler process for each file. Most modern languages are not designed to have a separate process launched for each file. Also resolving dependencies in a language like Java using Make is nearly impossible.

I once worked at a large network equipment company and shortened its build process from three hours to like 20 seconds by converting its build to Ant (a Java build tool, modern at the time).

A shell script is also usually a bad move in the end. I recently wrote a shell build for a lab because I didn’t want everyone to have to download a whole Java tool set to run one little lab. I thought it was a good move, but it was a noob mistake (as always) because the next version of the software it depended on broke everything (as always). Had I sucked it up and provided a modern build tool, it would have been able to update the dependencies.

Noob mistake 2: Use an IDE as a build tool

Most IDEs have some magic build/deploy thing. These seem nice at first, and indeed they are great for just testing your own simple code. But eventually you have dependencies and other people working on your code. Then you just don’t know why it builds on one machine and not the other. You need a repeatable build that can be run in a continuous integration tool and outside of your IDE. Something that can be staged and done as part of a release process.

Noob mistake 3: Terminate an AWS instance

“Terminate” in AWS means “delete everything”—not the “end process” meaning it has in most other tools.

The first major Amazon Web Services project I was on, a developer had assumed that a tool to read attributes would be safe to run. Unfortunately there was a terminate attribute where, if read, actually terminated the instance. He ran it on everything and terminated more than 100 instances. AWS has made it harder to make these kinds of mistakes, but frankly “terminate” should have been called “destroy permanently” because developers terminate processes with glee knowing they can relaunch them. But if you terminate an AWS instance, you lose everything!

Noob mistake 4: Test on something you care about

The aforementioned developer made another noob mistake: He tested on everything we cared about. Instead, he should have tested on a single instance that he created just for testing. Even if you think what you’re doing is harmless, test that assumption safely.

Noob mistake 5: Seek absolute data integrity

I’ve seen more than one developer use READ_SERIALIZED and use table locks because they wanted really, really good data integrity. There are other lock-producing obsessive-compulsive disorders. They all amount to bad schema design and unrealistic understandings of data, concurrency, and risk.

Noob mistake 6: Put code in your HTML or HTML in your code

Whether it is ASP, JSP, PHP, CGI, or straight code, there is nearly always some way to shove code in the middle of HTML, and there’s nearly always a way to do something like out.println(“<p>This is a terrible idea</p>”);. There was a time and a place for this—and that time was like 1995.

Yet there are more modern permutations. I’ve seen some gross stuff people are doing with JavaScript that is pretty déjà vu. There is always a better way: a tag library, an event handler, … really anything but HTML code.

Noob mistake 7: Use the almighty list

I admit to doing this in prototype code when I’m not sure how the data is shaped, but I quickly abandon this practice once I know. People who started in high-level languages are the most guilty of this. What is “this”? Basically, instead of using a map, a tree, or a set, you stick everything in a list and sort it yourself too. Worse, you pick an array back list and keep inserting somewhere near the center.

The trouble with this kind of code is it tends to make it to production. Though, I guess it’s good to load-test the garbage collector or memory management in the operating system some of the time. !!!

Noob mistake 8: I <3 inheritance

Woohoo! You took a class on decomposition. You decided that your first best step was to totally organize everything into perfect class hierarchies. You forgot about just containing stuff or making your program functional—no, you’re going to make everyone learn how your brain works first and keep in mind an ugly set of parallel class structures. Oh my gosh, just go work for the DMTF now.

In other words, you can put out trash standards to give everyone headaches. Don’t!

Noob mistake 9: I <3 functional

You just learned all about functional programming. You think object-oriented programming was a big mistake and that everything should be stateless and functional. Good for you.

Except if I need to add one more thing to the code, if I have to unravel every single function call to add it, you have failed. You have failed miserably.

Noob mistake 10: I <3 global

Coding is hard, thinking is hard, and deciding the scope of something is hard. But you decided not to bother and just use the most public scope you could. You killed memory, your code can’t be parallelized, and there are thread conflicts. But, hey, don’t put yourself out!

Noob mistake 11: Use big mega-objects

Once when I hanging out on a gig with a new trainee, I told him that the gig would go one of a few ways. One was that they’d throw the “big mega-object” into the session and wonder why “clustering doesn’t work” and why they ran out of memory.

Sure enough, when we arrived we found that they had a class file with hundreds of state variables and methods to permute them. Of course, they were shoving it into the session. Most of those things didn’t really need to go in the session and were there essentially for formation of a second-level database cache written poorly by hand. It was a huge waste of memory and replicating it was both thrashing memory and causing needless costly session replication.

Noob mistake 12: Death by a thousand objects

Just like you can have too few, you can have too many. Death by a thousand objects tends to come with noob mistake 8, I <3 inheritance, but I’ve seen it occur without inheritance. If none of your class files are 100 lines long and you have hundreds or thousands of them, you’re probably also doing it wrong.

Noob mistake 13: I can haz threading?

Most application code can be written with a single threaded view of the world. Although that breaks down when you start writing application servers, databases, or other infrastructure, most business software can be written using such infrastructure—so you don’t need to write those and thus go all multithreaded.

So don’t. Especially now that it’s getting easier to not write threaded code yet distribute and take advantage of threads. Look at how Spark works: You don’t go around constructing thread objects.

Noob mistake 14: Use of row locks

This really is a problem for SQL Server and DB2 users. The default database settings are for row locks on most platforms (DB2 does page locks on other platforms, which is worse). Oracle has less-stupid defaults. There used to be a debate about row locks vs snapshot isolation. Theoretically row locks are more efficient—until you have even one more thread with any possibility of contention (that is, nearly any modern piece of software).

Most developers don’t know what ”snapshot isolation”means let alone, how to turn it on. So things start mysteriously hanging in production under load because they’re using row locks b. Learn about snapshot isolation and how to use it properly. Avoid row locks.

Noob mistake 15: Use of sequences

Repeat after me: I will not use database sequences for unique keys unless I actually need sequential values. (Which is very rare.) Therein lies locking and remoting in one “convenient” painful package.

Instead of single-threading everything through the database sequence generator, you can use a 128-bit UUID backed by a secure random generator. If you’re afraid of duplicates, either you’re bad at math or you don’t value your life as much as your data. You have a far better chance of being hit in the head by a meteoroid even after you’ve generated a trillion IDs.

Hopefully, you respect yourself, your profession, and whomever has to maintain stuff after you. So don’t do this stuff. Even though you probably are: After all, even experienced developers sometimes make noob mistakes. Go forth and sin no more.