< writing /
29 Mar 2018 | Seattle, WA
We all write bad code. Every company that hires software engineers, from a two person start-up to a multi-billion dollar corporation, has some repository of code. In almost all of them, there exist at least a few lines of poor syntax, confusing variable names, and unreadable functions. The ubiquity of bad code must evidence its vital nature. If an engineer wants to demonstrate his or her value to a company, the ability to provide such important work is paramount.
For both veterans and newbies to programming, I have collected five tips for achieving this goal.
As the roman poet Quintus Horatius Flaccus maybe once said,
“Don't think, just do.”With all great quotes, it is important to ignore context and apply their values universally. In this spirit, we turn to programming. Sketching the structure of your program on paper, breaking that structure down into fuctions, and pre-emptively reducing redundancy can lead to elegant and readable code. We want none of that! My advice, just open the terminal, type "vi new_proj_12afsui.java" and start click-clacking away at that keyboard.
Naming variables and functions is a time-consuming task. Rather than waste the effort thinking, develop a standard naming convention. Feel free to use this example!
a = [8.50, 8.99, 3.99] b = ["trout", "salmon", "cod"] def func_1(a_list, anotherList): return zip(a_list, anotherList) def func_2(some_list): return sum(some_list[-2:])
You are very smart. You'll remember in a few months that func_2 sums the last two values of your fish prices... or was it lengths? Was this for the grocery store or the... the guy at the docks? Anyway, you'll remember. I promise.
Our intention to write bad code is ultimately in the service of climbing the career ladder. Another important part of this is never showing weakness. When you run up again a problem you don't know how to solve, the worst thing you could do is ask a colleague for her perspective. You don't want anyone to know that you lack knowledge in a specific area and want to improve. Despite your best efforts, if someone tries to give you helpful advice, discourage them from trying to improve your code by talking down to them and acting certain of your prowess, even when you know you might be wrong.
Each language has idiosyncrasies. When you use one you are not used to, it can be hard to remember whether array indices start at 0 or 1, how to structure hash-tables, what the correct indentation is, or which functions are reserved. A good editor will guide you toward choosing the best practices. Instead of using these suggestions, write in an editor that bows solely to your will.
When you get tripped up on a detail, don't search the web or ask for help (see tip 3), just try your best and guess what you think the solution might be. Then tag the line with a comment (e.g. idk if right... fix later). When your program is written, if it crashes or doesn't compile, you will have a dozen or so places to check where things might have gone wrong.
A hatchet is an infinitely useful tool. With the blade, you can hack down a tree. The blunt end can be used as a hammer. Angling the blade into the head of a screw can help you drive it. Treat your favorite programming language like a hatchet. Use it no matter what kind of problem you want to solve. When you sit down to write some code, think "This will be a hatchet job."
I hope this has inspired you to blaze new trails of mediocrity in pursuit of truly bad tangled-spaghetti code. Be cautious on your journey. It is easy to fall into the trap of seeking the input of others and developing a growth mindset. Remember to keep your head and heels dug firmly in the sand. You'll be terrible in no time.