Senior developers might learn a thing or two as well

Erik van Baaren

Oct 27, 2020·9 min read

This advice is useful for both beginning and seasoned software developers. There are some jokes intertwined here, too, so you might want to put down that coffee mug.

1. Java is to Javascript like car is to carpet

Hopefully, you know that Java and Javascript are two entirely different things, despite their names. If you didn’t, don’t sweat it; many beginners get confused by it.

So why are they named so similarly?

This is a quote from an interview with JavaScript creator Brendan Eich:

InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?

Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

The JavaScript name results from a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun’s Java runtime with their then-dominant browser.

At the time, Java applets allowed you to distribute applications efficiently. It was not a bad idea. In fact, it was quite progressive for the time — it would make software distribution a lot easier. Unfortunately, Java was heavy to load and felt a bit clunky. Java applets never really took off.

JavaScript was meant to be a lightweight language mixed with HTML, to make simple HTML pages more interactive and compelling without requiring the heavy Java alternative. Nobody at the time would have predicted that JavaScript would evolve into the most used language in the world. It was just there, at the right time and the right place.

2. It works on my machine

Bad developers tend to write code that works on their computer but fails anywhere else. How’s that? It can have several reasons:

• They are using packages that are only installed locally and don’t mention them anywhere in the documentation
• They forgot to check-in essential files in the version control system
• They use the most recent, bleeding-edge versions of a toolchain that nobody else is using yet (or the opposite)

However, I’ve cursed at others more than once while trying to get their code to run, only to find out I was the one doing it wrong. So don’t judge too quickly!

A good piece of advice is to get your software to run inside a docker container. It forces you to define all the requirements for your software and document them through a Dockerfile as well. Once done, anyone can run your code, anywhere, including future you. You’ll thank yourself later on.

3. Some people, when confronted with a problem, think “I know, I’ll use regular expressions!”

…and now they have two problems.

Regular expressions are a pain. When you think you finally got it right for one document, it matches 70% of the next document you feed it. Arghh!

If you’re just getting started, know regular expressions can be quite a pain, and you might be better served with built-in methods, like .replace(), .trim(), and .subString(). Each language has methods like these, and they can, combined in the right way, often do the job. If you ask me, your code will be easier to read for others as well.

Sometimes a regular expression is the best tool for the job. I’m not saying you should never use them. But if you can, you might want to try the alternatives first.

4. The cheapest, fastest, and most reliable components are those that aren’t there

You should keep a system or piece of software as simple as you possibly can. This reduces complexity and the number of bugs that can be introduced.

A simple system, with the least amount of components, is:

• easier to understand
• easier to debug
• less prone to bugs and unexpected behavior

5. It works, but I don’t know why

Sometimes you fixed a bug, but you don’t understand why. We’ve all been there, more than once. I promise it’ll get better; keep learning and practicing. But never, ever leave it at this. Always make sure you understand your code. Don’t be ashamed and ask someone else if you need to.

The same holds for copy-paste code. Yup, we all use StackOverflow sometimes! But if you don’t understand the code: either don’t use it or ask someone else for help.

Creating or using code you don’t understand is also referred to as voodoo coding. It’s is a bug waiting to happen.

If you force yourself to keep going until you understand, you’ll become that senior developer much faster. Added bonus: you’ll feel more confident too.

6. Software is like cathedrals. First, we build them, then we pray

Perhaps this was true ‘back in the days’, but not anymore. If you’re feeling like this, you’re doing it wrong. These days, there are multiple ways to prevent building cathedrals:

• Develop in small iterations, constantly adding functionality to a working stack of code
• Write unit tests that test each function you write. In the most extreme form, you apply a method called Test-Driven Development. With TDD, you first write multiple tests that encapsulate all the requirements of a function. Only after that, you start writing the function itself in such a way that all tests pass.

7. Code never lies, comments sometimes do

Comments are often forgotten while you change your code. Sure, comments have a vital function, but if you can, don’t use comments and write more descriptive code instead.

There are three ways to document code:

1. Use comments inside of your code.
2. Write documentation in a separate document.
3. Write self-documenting code.

To elaborate on that last point, because that’s what I mean with writing more descriptive code:

• Use good design, so your codebase is easy to navigate and structured logically.
• Don’t try to save characters. Use full names for your variables, classes, and functions. So, instead of wm, name it windowManager. Instead of rf, call it readFileToString. This name helps tremendously when others — or yourself, after a few months of not looking at the code — try to understand what’s going on.
• Extract as much as you possibly can into functions and make these functions do one thing. Name them accordingly. For example, create a function that reads a file into a string, and name it readFileToString(String fileName). Without reading the code in detail, people will know what it does. Ideally, your code is a sequence of function calls like this that almost read like human language. Only when needed, the reader can dive in deeper. This code documents itself!

8. “I don’t care how; just get it done!”

That’s the sound of technical debt in the making. What’s technical debt, you ask me? Good question!

Technical debt is the accumulation of extra work generated by making bad choices or taking shortcuts. Imagine building a very high building. If you start with a weak base, the cost of properly rebuilding that base will grow as you keep building higher and higher. At some point, the cost of repair is higher than tearing it down and starting over.

Technical debt will eventually cost a company a lot of money. Now that you know the term and what it is, make sure to spot technical debt in the making and warn your teammates and superiors.

9. Cheap, fast, reliable — Pick two

I love this one because it makes the ones hearing it (your managers) think for themselves:

• You want it to be reliable and fast? It can be done, but you’ll need to pay the best developers.
• Cheap and fast? Sure, but don’t expect it to be reliable! In fact, this is the recipe for creating technical debt.
• Reliable and cheap? Maybe, if you’re lucky. But it will take some time to find someone who can do it for cheap, or it will require a lot of iterations to get it right (or both).

10. Code as if the guy who ends up maintaining it will be a violent psychopath who knows where you live

In case you need that extra motivation! Sloppy code will eventually code around like a boomerang. Trust me.

11. There are two difficult things in Software Engineering

1. Naming things
2. Cache Invalidation
3. Off-by-one errors

Humans generally start counting at 1. Computers (and senior developers) start at 0. This simple fact has been the fuel for numerous bugs and difficulties. I’m sure you learned about this and know about it. You’re still going to make this mistake a couple of times.

12. The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

This one is from Robert C. Martin. If you don’t know why functions should be small and should only do one thing, please read points #4 and #5 from this article.

13. Beware of programmers who carry screwdrivers

This one does well on t-shirts. There are many programmers, but not that many software engineers. I mean, there’s a difference in being able to create scripts in Python vs. designing and building a complex software system, that must be maintained for the years to come.

14. A good programmer is someone who always looks both ways before crossing a one-way street

The best software can handle all errors, and I mean all. Even those that “will never happen.” Unit test the *&^% out of your code. The more tests you can afford yourself to write, the more reliable your code will be.

15. One bad programmer can easily create two full-time jobs a year

This is a scenario that happens a lot. There’s a problem that needs to be fixed, like right now! Some consultant is hired, does the job in a few days and leaves. Everybody is happy. Then, a couple of months later, someone needs to do maintenance on that piece of the system. Only to find out it’s a big, undocumented mess. The consultant has done a sloppy job, has another job by now, and is not planning on coming back to fix the mess. If you’re unlucky, a huge amount of technical debt has amassed as well.

It’s tough to deal with these situations. If you complain to management, you might come off as ‘difficult.’ Complaining to the person in question won’t help either: they don’t care or don’t even understand the problem. Just be aware that this is a common situation, and make sure this won’t affect you too much. You might even want to dodge the bullet and find another employer or project to work on.

16. Measuring programming progress by lines of code is like measuring aircraft building progress by weight

This one can be attributed to Bill Gates. More lines of code do not equal progress. The best code uses the least amount of lines to get the job done and is also the hardest to write. This is a well-known software principle, called “Keep it Simple, Stupid” (KISS for short). If you want to learn more about best practices like this, read my article “The 12 Habits of Highly Effective Software Developers”.

Thank you for reading. Please let us know in the comments if you have valuable advice to share.