Signs You Are A Bad Developer

Episode Breakdown

12:45 You don’t test your code.

Most people test, but many only test the “happy path”, that is, what happens when everything works. Test edge cases that are easily possible (missing files, security issues, missing network connections, bad user inputs, etc.). Test to make sure that your code REALLY works, and doesn’t just work if you execute a certain sequence of events in a row.

Document your testing, showing inputs, expected outputs, and actual outputs. If the actual isn’t equivalent to expected, it failed. Keep these tests for the next time you have to mess with it.

16:28 You never log anything or you log everything without being able to configure logging.

“You can create a lot of problems by not having a decent logging setup”

You can hook a debugger up to the code. That doesn’t help anyone in production troubleshooting some rare edge case that happened at 2:00 AM.

If you log everything, with no ability to control logging levels, it makes it extremely difficult to actually find what caused a bug. In any sizable code base, you should be able to set both the level of the logging as well as which components are logged in a manner that is configurable by a reasonably competent end user.

19:15 You think your framework is the best for all purposes.

“Use the proper tool for the job.”

This is wildly inaccurate, even with a subset of the market like the web. It also closes you off from learning things about other frameworks that may help you in yours. It is ok to say that the framework you are using is the one that works best for you. The problem is really more one of being overly rigid more than anything else.

“It’s Ok to say the framework is the best for what you are doing.”

22:48 You don’t spend time improving your skills.

“That’s the best way in the world to fall behind as the market changes.”

You’ll only find out how far behind you are when you get downsized and have to catch up. Developers make enough money to train ourselves, even junior developers.

“It shows that you do not prioritize your career.”

If you don’t, it’s not because your boss is cheap, it’s because you are cheap. This also can keep you doing things in an old, slow way, even if you are currently effective. Do you honestly want your boss in charge of what you are learning anyway? What if you decide you want to work somewhere else, doing something else?

27:18 You don’t understand databases.

It’s rare to find an application that doesn’t have to store data and most of them do it in databases. For a sizable percentage of applications, the data is the most valuable thing the application produces. If you don’t understand databases, you’re going to have a very difficult time troubleshooting common problems. And you’ll be a burden on everyone else around you.

“When I was first learning .NET the apps I was writing were CRUD (Create, Read, Update, Delete).”

SQL doesn’t change much over the years, so if you show that you don’t know it, it makes you look like you aren’t interested in putting in effort and never have been.

31:00 Your reaction to anything new (or anything old) is “ewwwww!”

“Silverlight Developer: Will Code For Food!”

Old technology is on your radar because it gets something done. It may be slower than what you’d like or not have the features, but it did do something worthwhile at the time. Similarly, new technology is on your radar because it offers some opportunity. Now, if you’ve been around long enough, it may be an opportunity that you’ve seen before, but you are still being unwise if you ignore it, as whatever made it bad last time might not be as big of an issue this time.

“We like to make fun of COBOL and FORTRAN programmers but they’re still running critical systems on that.”

Other people use those technologies. If you go around insulting them, are you really undertaking an action that will help you and your team achieve their goals (especially if you are trying to port from that tech or port to it)? Does it make you look good to emotionally dump on something, rather than using your wits to figure out how to make it useful?

35:00 You don’t understand networking.

“There’s a lot of levels of abstraction, but by the time you are a mid-level developer you should understand networking.”

If you can’t set up networking on your own computer, then you need to stop developing and go learn how to do that. Don’t be helpless in regards to something so critical to your success, as not everything is going to be on your computer. If you develop on a single machine, but your deployment environment is on multiple networked machines, it’s very easy to end up with code that is slow once it gets deployed, especially if you don’t understand the networking stack.

38:06 You can’t actually deploy software on your platform and/or do light server management on whatever it runs on.

This is either part of your job, or someone is going to be coming to you who has it as part of THEIR job. It’s not reasonable to be clueless on this. Be thinking about deployment difficulty when coding anyway, or you are creating problems for someone in the future.

You should be automating this anyway, because it’s tedious. But you don’t want to be in reactive mode all the time when a deployment is supposed to happen.

39:18 You are terrified of the command line.

“Are there really developers that are terrified of the command line?”

The command line is the old structure that a lot of things are built on. Things are still built on it. You will build things on it (including build scripts). Fear of the command line will make competent developers mistrust you in general.

The command line is also a much better way to do a lot of things, as it doesn’t require wasting time with a mouse. Once you master shell scripting, you can start automating some of your recurring tasks as well, leaving you more time for development.

41:45 You think “math is hard” is an acceptable reason to avoid doing something.

“It’s more of a thing of having enough confidence to say I’m going to solve this problem using mathematics.”

You don’t have to be a genius at statistics, or calculus, but some degree of ability to actually do computation is necessary for this work. If it isn’t for you, you are either in a pretty narrow specialization, or you haven’t done anything hard yet. It also evidences a lack of drive to actually get something done. Most things can be handled at the level of trigonometry or below, with maybe a little statistics thrown in.

“I learned boolean algebra in a philosophy class.”

You should also be able to do boolean algebra, because you’ll see it everywhere. It’s how binary logic is processed.

“The more you know about math the more you can estimate”

This also doesn’t mean that you can’t do back of the envelope guesstimates either They work sometimes but you have to have enough math skills to know when it’s safe.

50:11 You legitimately believe that you can do well without communicating with others.

“You’ve got to collaborate with other people to the degree that you are actually able to be effective.”

You can do well for a decent while without input, while working on something that is clearly defined, but you can’t do it forever. Isolation is the best way in the world to misinterpret something, and then chase it down a rat hole for weeks or months.

52:30 You don’t use the scientific method to figure out bugs or to test new ideas.

“Failures in this case will tell you a lot more than successes.”

You should form a hypothesis and test it, then examine the results to see what fell out. You need to know what the conditions of success are in order to form a hypothesis and test it. Don’t be one of those coders who blindly copies things from StackOverflow, trying desperately to glue enough pieces together that something works.

“I’ve made a career out of cleaning up after those sort of coders.”

You can’t just form a hypothesis either – you have to actually do something to prove or disprove it and it has to be capable of being disproven.