Christian Maioli Mackeprang

Author: Christian Maioli Mackeprang (Page 1 of 3)

You’ve been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

As programmers, we often have to join new projects, and the quality of the code can be all over the place. Even with an organized team, keeping code quality consistent throughout a medium-size-to-large project is a challenge.

That’s why understanding poor code quickly can be a valuable skill to have. It can help you become very productive in a short time and reduce the stress that usually comes with being the new guy and having to play catch-up. Being in a conversation with a co-worker and not knowing what that person is talking about half the time is a terrible feeling.

On the other hand, this is a prime opportunity for showing your client or boss your skills and that you can get up to speed quickly and impress them. Most developers take weeks to months to become really productive with a codebase they did not build themselves.

Ask for help

Other people have already learned how the code works, so why not ask them about it? You might think it makes you look like the newbie, but showing curiosity can have a strong impact on your image as an employee. If your boss’s expectation was for you to get productive fast without asking questions, that’s a misjudgment on her part.

Everyone takes time to get up to speed. Ask questions, and you’ll impress the people who have the right attitude for teamwork.

In many cases, the original developers will have made strange or unexpected decisions, and that’s where talking about the code will be much more valuable than reading it. This is even more the case if the documentation is lacking. Remember, existing developers have valuable project knowledge that is not written anywhere.

Make a list of new concepts

There might be business concepts that are new to you or that are overly complex. It’s important to get clarification about them before trying to work on code that handles those concepts, to avoid misunderstandings that might take a while to figure out.

It might even be the case that those ideas are mislabeled or represented in an unexpected way in a database. Avoid getting stressed over wrapping your brain around that, and just go to the source and ask your co-workers about it.

In the same vein, there might be modules, classes, or entities that don’t have appropriate names. Make a note of them. Poorly named elements can lead to great confusion, so document them early, as well as anything else that will negatively affect your ability to think about how the code works.

Make it easy to reproduce bugs

By adding code versioning and a virtual machine such as Docker or Vagrant, you will greatly reduce the time it takes to reproduce a bug and to test your work on a new feature.

Any kind of misunderstanding about how the code works could lead you down a path of building the wrong thing, either because what you’re building might already be there and you haven’t seen it, or because things just don’t work the way you thought.

At this point, you want to have Git version control in your project. That way you’ll be able to go back to a stable release, or even just work on separate branches that can be discarded if needed.

It’s even possible to gain greater reproducibility with Git, since you can use the stash to add testing or debugging code while you dig into a hard-to-track problem.

To learn about your project’s architecture, take on configuration and documentation tasks early on.

The same can be said about VMs and reproducibility. They’ve become ubiquitous for any modern development team, but you will certainly run into projects that are not using them or even ready to run inside one. Sometimes your first step as a new team member is to document the steps you took to get an environment working, and eventually turn those steps into a VM setup script.

Build a diagram of components

A mind map of business concepts, an entity-relational diagram (ERD) of the database tables, and a simple diagram of code components can greatly help to reduce the pain of understanding new code. Don’t remember how something works? Keep that ERD open.

In fact, any graphical tool that helps you digest information quickly and have a ten-thousand-foot view of a project will be valuable. Other examples of tools that could help you there are dependency graphs, logs, and a map of the project’s technology stack.

One of the greatest time consumers in development is the integration point between systems. Having a global view of the project landscape will help you identify which integration points are interesting to examine. Those are the spots that have the most work put into them, and the most bugs.

On the other hand, technology moves fast, and there could be opportunities to replace large parts of the codebase with more modern and properly integrated solutions. An old framework might have developed a new and official way to solve a problem, or an entirely new library could have been developed with better compatibility in mind.

Use visualization and modeling tools to view the big picture.

Prepare for automated testing

Before you start breaking things, it’s always prudent to add relevant unit tests. The problem with testing and poor code is that poor code is usually tightly coupled and hard (if not impossible) to test. You can’t isolate components that are intertwined and indivisible.

In those cases, take a step back and test from farther away. Usually that means doing integration testing, for which there are many tools available. Web apps can be tested against HTTP requests, so it is at least possible to verify that the system will respond in the same way to the same inputs.

Integration testing has much worse performance than unit tests, though. Whenever you can, implement unit tests so you can have faster feedback on code changes. If that’s not possible, then opt for functional or even integration testing.

This step should shed some light on the parts of the code that need work. If there’s a large amount of tightly coupled code, that’s a good target for refactoring after integration tests are done, and then for unit testing later.

Identify unusual or inadequate coding strategies

It’s time to start doing some refactoring, but where do you start?

Usually, the best place is where things look weird, or where development best practices have not been followed. For web development, that could mean fat controllers with tightly coupled model code.

Keep in mind that the same strategies might be in use elsewhere. So if, for example, you identify that fat controllers are present, then it’s likely that previous developers did not attempt to have thin controllers. You can expect to see the same problem in other controllers as well, since that reflected the style or shortcomings of the development process before now.

At first, work on a small task

Fixing a small bug on a feature that is conceptually simple will be very enlightening and will help you feel productive from the start.

This is a similar idea to what Andy Hunt and Dave Thomas call “tracer bullets” in The Pragmatic Programmer. The underlying logic is the same: Work on something end-to-end to prove to yourself that it’s possible, and then progressively improve on that initial work.

The “tracer bullet” approach. Credit: The Pragmatic Programmer

A good example of the kind of simple improvement you can make is to take small refactoring steps with simple code. Identify a common programming practice that is not being followed, and apply it.

One of my favorites for this is un-nesting conditional blocks. So instead of having several if-if-if blocks, one inside the other, negate the first one and return, and do the same for all validation-type checks you can find. This can be as simple as inverting an “if” check and moving some code around, so the risk is almost non-existent and the flat code will be easier to read.

Be sure to work first on refactoring features that are easy to test, because even though the changes are low-risk, it’s always a good idea to be able to validate your code before sending it to production.

Get on familiar ground before tackling critical code

Always learn how the project is set up first, and only then dive into the architectural side. The most critical pieces of business and integration code are the hardest to understand and modify. Avoid getting into trouble early on.

As a general rule, avoid business issues that would require you to know more than you currently do about the project, or about the business side. That usually means to stay away from transactional, payments or math-heavy code until it’s starting to become familiar ground.

Once you are productive, comfortable with the coding style for the project and have no trouble fixing simple issues, it’s time to work on the harder stuff—but not before.

Even if there is some urgency for fixing payment issues, for example, that kind of task can be incredibly risky. A mistake there could cost the project dearly, and that will be on you as well. Absolutely refuse to work on high-risk tasks early on, if at all possible.

How to deal with an unfamiliar tech stack

For the last point, a common problem I’ve run into is that every new project usually includes some technology that I’m not familiar with.

When that happens, I have a couple of strategies that help me get up to speed fast. The obvious path for learning is reading documentation and getting familiar with the new technology. But while you will learn a lot about structure, that path will not help you learn the corner cases, which typically come with experience. (“Corner case” is an engineering term that refers to a situation that occurs outside of normal operating parameters.)

One way to speed up this process of gaining experience is to take question-based resources such as Stack Overflow and Quora and just read through them like a book. Find the most popular questions about the library you’re learning and see what kind of problems other people typically run into. You’re not going to necessarily run into them yourself, but just knowing what’s possible is like shining a bright light onto your mind map of those new ideas.

Leverage Stack Overflow questions to gain experience fast. Credit: Stack Overflow

For a more targeted approach, find information about library features being used in your new project specifically. Look into those that are new to you and learn them ahead of time, before you have to touch that code at all.

Use Task Familiarity to get More Accurate Estimates

By Christian Maioli Mackeprang

On October 20, 2017

In Uncategorized

From the first time I did an estimate, it seemed evident to me that previous experience with a task is tremendously helpful in estimating it accurately. For instance, if you’ve installed a particular library a bunch of times, you should at this point have a good idea about how long that usually takes you, right?

What the current methodologies do

Each person on a team has different levels of familiarity with each task, so it doesn’t matter if one person estimates all tasks, or if you take an average from estimates done by several people. In both cases, there is loss of valuable information.

Strangely, this familiarity factor has been largely ignored by teams I’ve worked in. My current one does “planning poker” for example, which tries to have a few people agree on an estimate. Problem is, what if only one of them has actually implemented such a task before? The weight is on that guy to get everyone else to agree with him. Averaging estimates can lead to completely useless results.

Waterfall had a similar, if not worse, problem. Usually in that kind of environment, the team leader would do the estimating, or he would defer that to another team member. Again, programmer experience was ignored. Never have a single person do all the estimating.

Peer pressure sweeps the problem under the carpet

Another relevant factor that is usually ignored during estimates is: who is actually going to implement it? Certainly, the estimate cannot be accurate if you label a task as low complexity and then assign it to someone with zero previous experience with such a task. This problem cannot be avoided by any system that separates estimating from implementation.

Some teams try to mitigate this by having the implementer re-estimate it, but then you are wasting time estimating it twice and, in my experience, if the estimates differ greatly, there is going to be peer pressure on the implementer to try to get him to agree with the previous estimate.

The benefits of focusing on task familiarity

An interesting thing about paying attention to task familiarity, is that it seems like people have no interest at all in gaming this metric. They know that they either do or do not know something, so there is naturally going to be less guesswork.

If you love numbers, you can run a survey in your team to measure how familiar each person is with each task. By starting from more accurate data, your conclusions should be more valuable.

Start by building a table with team members and tasks, and have each cell be a number from 0 to 10 measuring how familiar each member is with that task. Having done that, you can use that table to help you make decisions and to calculate valuable things.

Measuring how familiar each person is with a task can give you valuable insight on your team

To maximize implementation speed, simply assign each task to the person most familiar with it.
To maximize the potential of your team, have people learn more by assigning somewhat unfamiliar tasks to each one. Keep them in a challenging but not pharaonic effort level.
Get people up to speed quickly by teaming up new members with those that are already familiar with the tasks you’ve assigned to the new guys.
Build a general technology familiarity table for your team, measuring each tech (React, Angular, etc.) against how familiar each member is with it, which will let you know how much of an impact you’ll have by introducing the new tech into your stack.

Creative techniques for writing modular code

By Christian Maioli Mackeprang

On August 23, 2017

In Clean code

Modularity first started looking really interesting to me after I read the legendary SICP book. It surprised me to learn that for some people, making code understandable is so important that they write their own little languages just to make the program readable to anyone (the book also teaches you how to build an interpreter, an encoder, and other cool things).

Although SICP gives you a solid introduction to the art of modularity, it’s still hard to create your own vocabulary if you’re not using Lisp. For other languages, we have to get creative to be able to encapsulate code into bite-sized chunks.

Why and how to write modular code

Modularity exists entirely because of the human side of development. A computer doesn’t need a broken-down and embellished version of the code to be able to run it. It was our cognitive limitations that got us to write code in smaller pieces at a time.

A particular problem where this becomes obvious is when dealing with temporary contexts. For example, say you’re writing to a file but a condition arises where you need to write to another file. You need to temporarily forget about the first file and all of its related data to deal with the second one instead.

This kind of situation was confusing and overwhelming, so functions were invented. A typical way to handle this now is by making a function that writes arbitrary data to any file, to isolate the temporary context inside it.

Using variables to isolate logical expressions 🎲

What happens if the context is actually very small? Even a function might be overkill. Another way to handle temporary context is by putting logic inside variables. Taking advantage of the fact that logical expressions get reduced to a boolean value, most languages will let you do this.

We know that these small modularization ideas are beneficial when we can appreciate that code starts to read like a story, more than a group of disconnected formulas. When you make changes to your code, ask yourself: does this change make the implementation’s logic more evident or does it make it inscrutable?

Using nested functions 📚 to encapsulate blocks of code

Sometimes when you’re writing a function you realize that some of the code looks repetitive, so you decide to create another function. Most languages would require you to make the new function under the same namespace. This is where JS nested functions come in handy. You can place a function inside another one, so that the internal one can only be accessed from your original method.

An interesting property of this technique comes up when you use IDEs that have code folding. They allow you to fold the external and internal functions together in this case, which is much faster than folding individual ones.

Preventing data access 🔒 with block-scoped variables

Some languages such as C, C++ and more recently JavaScript (ES6) let you define variables that are only accessible within a block. That means that you can’t accidentally access that variable later, or in another iteration of the same loop.

These come in handy when you want to encapsulate data access to the smallest part of the code that you can. Any change you make to your code is bound to make ripples through your program. If you modify a lot of code, there will likely be a strong impact on the codebase. For a larger codebase, even a small change could have a large impact.

That’s why these features let you avoid bugs resulting from accidental data modifications. Block-scoped variables localize the impact of changes.

Although block scopes can let you reuse variable names, that’s not what they are most useful for. The real benefit comes from not being able to access the internal data. You’re creating a safety net so that when a bug comes up, you know that you can ignore internal variables if the problem is outside the block.

Why should I apply this stuff?

Identifying new ways to separate concerns in your code is important, because it lets your mind worry about less things when debugging. You should aim to keep a high cohesion and encapsulation, and having as many tools as possible to do that will make you more productive. Once you are used to focusing on making your code tight, you will have less bugs to worry about.

Cohesion and coupling are really important concepts for writing clean code. Fortunately, there are already many good articles about them. Here’s a great introduction to cohesion. If you’re not familiar with these ideas, the article is somewhat technical, but definitely worth studying.

Modularity sometimes causes more problems than it solves 🛑

After you begin to appreciate the value of breaking ideas down into smaller pieces, there’s a risk that you’ll see it as the silver bullet of clean code. You wouldn’t be the first.

Modularity is no panacea. Let me show you some examples where it causes more problems than it solves.

Excessive object-oriented structure

Programming using interfaces (contracts) is a very powerful idea. Taking advantage of that, some frameworks bring with them a whole set of interchangeable classes. For example, to handle persistence there might be several classes implementing the persistence interface. Unfortunately, IDEs get confused by this, so while reading code you will try to find the source of a method, and the IDE will not know which method you want to see, so it will show you a long list of files where a method with that name exists. It can be a real pain to have to sift through that list every time.

Modules that are too small

There are tons of JS modules out there that include just a single small function. Each module requires additional parsing and processing time, and includes their own header in the code, so using a lot of small modules will add overhead to your build system and increase your bundle size.

Centralization of dependencies

Excessive modularity has also caused problems due to the centralization of code, which happens once enough people start using a module. That was the case with left-pad, which was brought down, taking many projects with it for a few days.

Refactoring for the sake of it

Some code almost never changes. In those cases it might not make sense to try to make it look cleaner or to abstract logic that is only used there and that already works well. The other day I was reading the Redis code and a method stood out, “loadServerConfigFromString”. I thought, this code doesn’t look too pretty and yet, according to git blame, it has not changed much in the last 7 years. There is no reason to refactor code that never changes and already works fine.

Conclusion

One of my core philosophies when working with technical issues is always being aware that the implementation details alone will make or break an idea. Always be aware of where and how you are going to apply modularity, and how it affects the development environment.

Being Agile and working smart are not the same thing

By Christian Maioli Mackeprang

On May 26, 2017

In Agile

The discussion about software methodologies is not over. Agile did not win, nor did any other methodology. I’ve never worked in a team that hit the right spot in team dynamics and was as effective as possible, whether using incremental development or not. I think I’ve figured out what it is that still needs work in that area.

Most discussion about methodologies is about trying to find an ideal one. Should it be more structured? Less structured? How many meetings are we doing? You try a bunch of recipes such as Scrum, Kanban, waterfall; sometimes they work, and sometimes they don’t. It’s like aiming at a moving target.

The problem is not which recipe to use, it’s being aware of each one’s strengths and weaknesses. Teams need to know when structure is beneficial and when it’s not—and realize that achieving good team dynamics is a skill to be honed. You can’t write down a process plan and expect everything to magically be smooth sailing from then on, because project requirements vary in many ways that sometimes aren’t self-evident.

Even throughout a single project, using a single methodology is far from ideal. For example, are short iterations a good fit for a project that needs big design up front, no matter what? And if you use long iterations, what happens later when you realize your design is lacking in a specific area?

Looking over these issues, I’m going to make a case for why:

Being Agile and working smart are not always the same thing
An adaptive mindset means knowing when your methodology helps/hinders you
Office life and daily issues can completely change the effectiveness of your process

How development focus changes throughout a project

In a large project, the teams focus is constantly changing. When development begins, you might split the project into modules, with strong code ownership rules and laser-focused development.

Later on, when most modules are going through a debugging and testing phase, code ownership gets in the way. At that stage it’s more productive for a developer to go through his own short testing/debugging cycle and be able to fix bugs anywhere, and excessive communication would slow her down considerably. Although someone with more knowledge about a module will be more productive when working on that part of the code, on the other hand, more eyes on the same piece of code will lead to less defects.

Perhaps the realization that things change constantly is what brought us to have more granular methodologies like RUP, with it’s bazillion roles and artifacts. A highly dynamic methodology like RUP requires people to learn new habits constantly. It’s hard to even get people to make a stand-up last 15 minutes. I don’t want to know what happens when you make them jump through 10 times as many hoops.

More structure means more concepts to learn, a higher cognitive load, and a harder to apply methodology. If the question is how to make the work flow as smoothly as possible, then jumping through more hoops is not the answer.

Is it right to use Agile everywhere?

Agile is lightweight, easy to implement, and the project’s direction can be adjusted based on completed work, not on speculation or predictions. It can adapt better to changes, but sometimes it prevents you from going where your project needs you to go. Here are a few cases where it’s iterative process doesn’t work so well:

You need a big design phase up front. You need precision and don’t care so much about development time. Anything NASA does would fit here.
Your business has a high cognitive load. It’s hard for users and/or developers to get it, so you need a lot of well-organized documentation. Enterprise software. Financial software.
You’re doing a complete rewrite of your software, so your team already has a clear idea of where to go. Requirements are clear, and there’s not much need for course-correction anymore.

There is a lot of focus right now on getting the kinks of Agile just right, and it’s a productive mission because most teams don’t get it right. On the other hand, to realise the full potential of your team you need to know when to switch things up, and when Agile is setting you back.

Besides those specific cases, it’s a good idea to always keep in mind the disadvantages of Agile:

It requires high customer commitment. Some customers are too busy for that.
Requires constant and/or automated testing. Some customers don’t want to spend money on that.
Huge communication overhead for remote teams. Prepare to spend more time setting up WebEx/Skype and on IT issues than actually writing code.

These problems are responsible for the fact that most companies today are applying some kind of hybrid Agile process rather than staying true to it’s principles. But it’s important to know why Agile exists, what problems it solves, and when to stick to the core Agile principles. This is why I said that achieving good team dynamics is a skill.

When to make changes to your team

Typically a team stays mostly the same throughout a project, but as the project progresses, it’s unlikely that everyone’s strengths are being leveraged at all times. People are good at different things.

Generally speaking, more experienced team members are better leveraged by having them use their experience more than their mechanical skills. The inverse is true for the least experienced.

Put both kinds of developers to solve a restricted coding challenge and the more experienced one might do it slightly faster, but he knows he can entirely avoid writing any code by just calling a specific library that a less experienced developer won’t even know exists. That difference in experience may well be where the “10x programmer” expression comes from.

One of the main focuses in modern software development has been in reducing cycle times, but they are an incomplete measure of team productivity. Getting stuff out faster will let you adjust more often, but that won’t help you if you’re not willing to use the right people for each problem, and taking their specific experiences into account. Familiarity with a problem is a huge leverage point, and modern methodologies throw it under the rug when they turn the whole team into numbers, each one with identical weight.

Adapt your daily routines to your current team

The final aspect you have to look at when you want to be a fully adaptive team is the details of your daily routines. These can make or break your methodology’s effectiveness.

I remember being in an Agile team where the daily standups were contributing almost nothing due to several factors. You might have seen it yourself, when noone has anything to report in the standup for days in a row. The thing that still made standups effective in that case was the fact that my desk was literally 2 meters away from where we would meet every morning. The effort to get there was so small that it didn’t matter.

A poor implementation of a methodology can still work if the specifics are adjusted to make up for the issues.

I’ve also seen the opposite situation, where you have a well applied methodology that is made worthless by the accumulation of small daily issues, like video conferencing software that never works and poor hardware or infrastructure.

The bottom line is that to make your development process work, you have to take a hard look at who you’re working with, how they like to get things done, and what resources you have at your disposal, and then make every effort you can to help your team stay in the zone. Make the working environment comfortable and effortless and the work will flow.

If your team has lots of experience, trust them, and help them enjoy getting things done. Don’t undermine the relationship by requiring them to jump through hoops to get work done.

Note: this post was originally featured on TechBeacon.

Avoid these 35 habits that lead to unmaintainable code

By Christian Maioli Mackeprang

On May 4, 2017

In Clean code

Bad habits are hard to break and even harder if you don’t realize that what you’re doing is undermining your work. If you know but don’t care—that would be the worst. But you’re here, aren’t you?

As a programmer, I’ve seen a lot of poor practices, not just around code, but also around teamwork skills. I’ve been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.

Code organization

1. Saying “I’ll fix it later”, and never doing it

The habit of postponing code fixes is not merely a problem of priorities. Organizing your issue tracker might generate some progress, but you also need to have a way of tracking smaller issues that come up. Adding “TODO” comments is a quick way of making sure you don’t miss anything.

2. Insisting on a one-liner solution

Being obsessive about writing efficient, elegant pieces of code is a common trait of programmers. It’s like solving a puzzle—you find a combination of functions and regular expressions that turn 20 code lines into 2 or 3. Unfortunately, it doesn’t always result in readable code, and that’s generally the far more important outcome. Make your code accessible first, then clever.

3. Making pointless optimizations

Another place where we often misplace our efforts is optimizations. It sounds great to reduce the size of your website a few bytes, but won’t gzip make up for it anyway? And aren’t requests more important? Address optimizations at the end of a project, because more often than not, requirements will change, and your time will have been wasted.

“Premature optimization is the root of all evil.”
—Donald Knuth

4. Convincing yourself that styling issues are not that important

If I’ve learned anything over years of looking at other people’s code, it’s that dealing with coding style issues is the thing that developers are most likely to postpone. Maybe it’s hard for inexperienced coders to see what good will come out of addressing styling issues, but over time it will become evident that once code quality derails, a snowball effect will turn any project into a complete mess. Be strict about best practices even if they seem negligible. Set up code checking and linting tools to give yourself space to worry about the more important things.

5. Sweeping things under the rug

Either by catching and ignoring exceptions, or by using libraries that don’t report errors (such as jQuery), there are many ways to sweep things under the rug. But when one of those errors becomes a priority, the challenge of fixing it will be many times greater, considering that you won’t have a clue where to begin. An easy way to avert this is by logging those ignored errors so you can study them later.

6. Using names that don’t add information

Naming is hard, but there’s an easy way to make sure your variable and function names are at least of decent quality. So long as the names add some kind of information that the rest of the code doesn’t convey, other developers will have an easier time reading your code. The reason that naming is so important is that names can give a general idea of what the code does. It takes more time if you need to dig into the calculations to figure out what piece of code does, but a good name can help you understand what the code does in seconds.

7. Ignoring proven best practices

Code reviews, test-driven development, quality assurance, deployment automation—these practices, and several others, have proved their value in countless projects, which is why developers blog about them constantly. A great reference for these best practices is the book Making Software: What Really Works, and Why We Believe It. Take the time to learn how to do them properly, and your development process will improve in all of your projects in ways that will surprise you.

Teamwork

8. Abandoning plans too early

A sure-fire way for making your system inscrutable is to not commit to a plan. You can always say, whenever your code is criticized, that the plan isn’t complete. However, having half-done modules will lead to tightly coupled code as soon as you try to make those unfinished modules work with each other. This kind of complication also comes up when a project’s leadership roles change and the new leads decide that having it their way is more important than architectural consistency.

9. Insisting on a plan that has little chance of working

Just as abandoning your plans can cause problems, so can sticking to a plan that doesn’t work. That’s why you should share your ideas with your team to get feedback and advice when things get tricky. Sometimes a different perspective can make all the difference.

10. Working on your own all the time

You should strive to share your progress and ideas with the team. Sometimes you think you’re building something the right way, but you’re not, so constant communication is very valuable. It’s also beneficial for other people when you work with them. Their work often improves when you discuss ideas with them and mentor the less experienced members of your team, who are more likely to get stuck.

11. Refusing to write bad code

There comes a time in every developer’s life when deadlines will force you to write terrible code, and that’s okay. You’ve tried warning your client or manager about the consequences, but they insist on sticking to the deadline, so now it’s time to code. Or perhaps there’s an urgent bug that can’t wait for you to come up with a clean solution. That’s why it’s important to be versatile as a programmer and to be able to write poor code very quickly as well as good code. Hopefully, you can revisit the code and pay back the technical debt.

12. Blaming others

It’s no secret that arrogance is an all-too-common trait among developers and other technical professionals. Taking responsibility for your mistakes is a virtue that will make you shine among your peers. Don’t be afraid to admit that you’ve made a mistake. Once you’re okay with that, you will be free to focus on learning why you made that mistake and how to avoid it. If you don’t own up to it, learning becomes impossible.

13. Not sharing with your team what you’ve learned

Your value as a developer is not only placed on the code you write, but also on what you learn when writing it. Share your experiences, write comments about it, let others know why things are the way they are, and help them learn new things about the project and its intricacies.

14. Being too slow on giving feedback to managers/clients

One of the most valuable character traits of any craftsman lies in making sure that everyone is on the same page about the work, as much as possible. The reason for this is not so that your manager call fill spreadsheets. It’s for your own gain as well: You will have fewer insecurities and reduce uncertainty about the lifetime and future of the project.

15. Not using Google enough

The best way of solving a complex problem quickly is not having to solve it at all. When in doubt, Google it. Of course, you can bother the engineer next to you instead, but rarely will he be able to give a response as detailed as Stack Overflow, not to mention that you’ll be interrupting his work as well.

16. Overvaluing your personal style

Always aim to coordinate your working style and environment setup with your team. Ideally, everyone on your team should be working under similar conditions and following the same coding style. Doing things your way can be more fun, but co-workers might not be used to your coding style, and if it’s unusual, it will be harder for the next developer to work on what you’ve built.

17. Having a personal attachment to your code

When someone comments on your code, don’t take it personally. Your code should stand on solid ground; that is, you should be able to explain why you wrote it that way. If it needs improvement, that’s only a reflection of the code’s correctness, not of yourself.

Writing code

18. Not knowing how to optimize

A good optimization strategy takes some experience to get right. It takes exploration, analysis, and knowing every system involved in a process. Inform yourself about these things. Learn about algorithmic complexity, database query evaluation, protocols, and how to measure performance in general.

19. Using the wrong tool for the job

You can only know so much, but the reason why you have to keep learning is that each new problem brings a different context and requires a different tool—one more applicable to the task at hand. Be open to new libraries and languages. Don’t make decisions based strictly on what you know.

20. Not bothering with mastering your tools and IDE

Each new hotkey, shortcut, or parameter you learn while using the tools you work with every day will have a more positive effect on your coding speed than you realize. It’s not about saving a few seconds by using a hotkey; it’s about reducing the context switching. The more time you spend on each small action, the less time you’ll have available to think about why you’re doing it and about what comes next. Mastering shortcuts will free your mind.

21. Ignoring error messages

Don’t assume that you know what’s wrong with your code without even reading an error message, or that you’ll figure it out quickly enough. Having more information about a problem is always better, and taking the time to gather that information will save more time in the long run.

22. Romanticizing your developer toolkit

Sometimes your preferred editor or command line tool isn’t the the best tool for the job at hand. Visual Studio is great for writing IDEs, Sublime is great for dynamic languages, Eclipse is great for Java, and so on. You might love vim or emacs, but that doesn’t mean that it’s the right tool for every job.

23. Hardcoding values instead of making them configurable

Always be thinking about what changes might come and how to deal with them. Technical debt will grow at a monstrous rate if you don’t separate the moving pieces from the rest of your work. Use constants and configuration files where appropriate.

24. Reinventing the wheel all the time

Don’t write code you don’t need to. Perhaps someone else has spent a good deal of time on your problem already, and he or she might have a well-tested solution that you can reuse. Save yourself some trouble.

25. Blindly copy/pasting code

Understand code before you reuse it. Sometimes you don’t immediately notice everything the code is doing on first glance. You will also learn more about a problem when you take the time to read the code in detail.

26. Not taking the time to learn how things really work

Always take the opportunity to expand your knowledge by thinking about how things work and reading about their underlying issues. You might save time by not bothering right now, but what you learn on a project will be more important in the long term than actually getting it done.

27. Having excessive confidence in your own code

It’s dangerous to assume that just because you wrote something, it must be great. You learn more about programming as you work on new things and gain experience, so take a look at your old code from time to time and reflect on how you’ve progressed.

28. Not thinking about the trade-offs of each design, solution, or library

Every product has its fine points that you’ll only learn about by using and analyzing it. Seeing a few usage examples for a library will not make you a master of it, nor does it mean that it’s the perfect fit for every situation that will come up in your project. Be continually critical of everything you use.

29. Not getting help when you’re stuck

Keeping a short feedback loop will always be less painful for you. Asking for help doesn’t mean that you’re incompetent. The right people will see your effort and admission of ignorance as a drive to learn, and that’s a great virtue to have.

Testing and maintenance

30. Writing tests to pass

Writing tests that you know will pass is necessary. They will make refactoring and reorganizing a project much safer. On the other hand, you also have to write tests that you know won’t pass. They are necessary to move the project forward and keep track of issues.

31. Disregarding performance testing for critical cases

Prepare an automated performance testing setup at about the middle point of a project’s development process so you can make sure you don’t have escalating performance problems.

32. Not checking that your build works

It’s rare when a build passes but doesn’t really work, but it can happen, and it might be troublesome to fix the problem the longer you wait to look into it. Quickly testing every build is an important habit to have.

33. Pushing large changes late, or leaving after making a large push

This is where overconfidence will get you, and it can take getting burned multiple times to learn why you shouldn’t do this, so take my advice now and make sure you are always there when your build eventually breaks.

34. Disowning code you wrote

Be willing to support code you wrote. You are the most suitable person for helping others understand it. You should strive to make your code remain readable to yourself and others many years from now.

35. Ignoring the nonfunctional requirements

When you’re trying to deliver something, it can be easy to forget about some important areas such as performance and security. Keep a checklist for those. You don’t want them ruining your party because you drew up your deadlines without thinking about these nonfunctional concerns.

What are your worst programming habits?

As it’s often said, we are creatures of habit. Improving the way you work through habits is a great way to avoid having to think too much about every single situation. Once you’ve assimilated a good way of doing something, it becomes effortless.

Note: this post was originally featured on TechBeacon.

Code: The Hidden Language of Computer Hardware and Software	The Pragmatic Programmer: From Journeyman to Master
Code Complete: A Practical Handbook of Software Construction, Second Edition	Growing Object-Oriented Software, Guided by Tests

Code: The Hidden Language of Computer Hardware and Software	The Pragmatic Programmer: From Journeyman to Master
Code Complete: A Practical Handbook of Software Construction, Second Edition	Growing Object-Oriented Software, Guided by Tests