![]() ![]() Let’s say you’re writing a function that takes a list of widget prices and returns some text with the average of those prices. Write small functionsĪim to write small functions that do one thing. Now that we understand why maintainable, clean code matters, let’s talk about how to write it. If other people you work with can embrace these practices, you’ll spend less time struggling and more time collaborating productively. Writing “clean” code (as it’s often called) will help you think through the problem. In order to make code easy to maintain, update, and fix, it should be modular, easy to follow, and easy to reason about. How long would it take someone to update my script to work with the new layout? If another developer offered to help, how long would it take them to get up to speed on my work? That depends on how well the code was designed. Good design “reduces the cost of future changes.” Let’s say my company changed the layout of the discount code page. It took me two hours to code the script, but eight hours to undo the damage it caused and fix my convoluted code. But the following week, the script went haywire and applied the code to 300 wrong accounts. I hacked the script together in a few hours, and, to my manager’s delight, it pasted hundreds of codes in a few minutes. At the time, this task was done by hand for hundreds of users each month. This doesn’t mean your code was badly written or buggy! Requirements evolve, other parts of the code change, and sometimes… well, yeah, sometimes there are bugs.Īt one of my first (non-programming) jobs, I wrote a script that switched between browser tabs with user accounts and pasted in discount codes. Once you write the code, other people (including future you) will invest two to three times as much time, on average, in reading, updating, and fixing it. There’s an adage in programming that maintaining code is 75% of its total cost. It helps if you are familiar with variables, functions, and if/else statements. This post is aimed at people who’ve spent time writing code, but don’t write it professionally full-time. We’ll keep our examples short and simple and write them in pseudocode (which should seem familiar if you’ve written in a popular language). So we’ll assume you already know how to pull together a working solution - it’s time to level up to Coding 102: writing code with and for other humans. Beginner tutorials usually focus on syntax. But these practices aren’t usually discussed in “Coding 101”. There’s a lot to learn about basic programming beyond “making it work.” For professional developers, writing maintainable code is fundamental to the job. And since more of us are writing and collaborating on code than ever before, it’s becoming crucial to write better code. To a developer, it’s only the starting line. To a beginner, getting a working solution is the finish line. The bad news is that after you write the code you just learned to write, someone is going to have to read it (that someone might be you in six months). So, if someone at work hands you a Python script to run over some data, between Stack Overflow and Codecademy you can probably figure out how to get it to work. There’s no shortage of beginner-friendly programming tutorials, and high-level languages today are more readable than ever. The good news is that it’s easier than ever to write code that works. In everyday offices, classrooms, and laboratories, code is now being written and maintained by people who don’t think of themselves as programmers. Something similar has happened with programming over the past decade. You no longer had to be an engineer to use a computer. With the release of the Apple II in 1977 and the IBM PC four years later, a tool once reserved for scientists and the military proliferated in accounting offices, universities, and hospitals. ![]() In the 1980s, personal computers became common in the workplace. ![]()
0 Comments
Leave a Reply. |