How to Super Charge Your Web Design Skills This Year

Have you ever been on an agile project where the sprint goals, deadlines, and the pressure of completing tasks, took over the opportunity to make some wiser decisions? If you are a developer, you’ve probably seen the quality of your code being affected by that. This is what this blog post is going to help you fight against.

I need to mention that the company you work for needs to have the will to apply the actions that lead to building products with a high code quality underneath. In opposition to, for example, the business model of a high-speed delivery software factory is generally based on offering cheap development services and building simple apps with the hope to catch some attention to skyrocket investments.

Moving on, if you already have a suspicion that focusing too much on delivery could negatively affect your project and you want to start the ride towards a solid eye-catching codebase, put on your armor and keep scrolling down.

Why aim for code quality in agile?

Save your team from hell

There is something very important we say at LoopStudio - It won’t be long until you find yourself facing an awful code without really realizing how you’ve got there. Once you are in that situation, it will become increasingly harder to understand what’s going on, and as a consequence, it becomes painful and stressful to work on that project.

You are in an industry where you can get creative and enjoy what you do. Not many people can say that, so don’t waste that opportunity by turning your job into a nightmare!

Bad code, bad results…

As much as someone wants to detach how code is written from the ability to produce successful results, it’s just not possible. Everyone makes mistakes, so bugs and other issues are expected to appear in your app at some point.

However, if your team doesn’t feel comfortable around the code, it’s quite likely that more stuff will go wrong. Being in a constant state of uncertainty, stress, and uneasiness will fall into making rushed decisions that lacked a proper analysis, and probably a poor review too.

Do it for yourself

As a developer, you want to grow constantly and in many ways. One of the main growth areas is strengthening your technical skills. Even though creating robust pieces of code may require you to be in a partially structured environment, once you are there, you depend on yourself to walk in that direction. It’s an efficient career path.

Hold on… What is code quality anyway?

So far, so good, right? But we haven’t defined what code quality is, and the reason is that it’s not easy to come up with a definition. If you put 10 tech leads of the most resounding companies out there and ask them how a piece of code is supposed to look, they will probably have many disagreements, so why would I know better?

The thing here is that you have to figure out the real meaning. It’s up to every development team to establish and perform around what they're committed to. However, I can give you the tools to identify if your code fulfills that objective and therefore, make it shine. Fair enough?

Awesome! So this is the picture you are looking for:

Your codebase should be just as clean, understandable, and maintainable in every phase of the project. Everyone on the team has to understand and back up how it looks, to keep building in the same fashion. The maintainability of your project can’t decrease unless in certain situations or emergencies, of course.

The cold translation is that the team has to be aware of every single line of code that went into the repo, which can mean one of two things: either the current state of that code is the desired one, or it’s tracked as technical debt. Too harsh? Out of reach? Don’t panic, you are one step closer to pulling it off…

Unveiling the tactics: How to do it

You don’t get what you don’t seek

Overall quality is an attitude. Whether we are talking about a pretty design, a performant app, or a solid architecture, you will make it just if the team is focusing its effort there. However, the first person to determine the nature of all this is the PO (Product Owner). If the app you’ve been building has a very poor UX because of the rush to get features working at their most elementary level into production, the designers and developers are not to be blamed for this. They did what was asked in the short time they had.

Basically, you can’t go further than what your context allows you. This could even mean that you should switch projects or your job if you’re sure it’s what you want. Anyhow this turns out to be, the first step to accomplishing any kind of results is to identify the goals of the project and push in that direction.

Conquer, or die…

Once established that you are creating a high-caliber product, you’ll enter one of the hardest parts of this journey: selling your programming standards. How can you justify to the PO that your development approach will add up some points to the sprints? No one will be able to tell any difference by using the app…

Well, this is where we have to re-visit our driving force to start this whole case, and that is the ability to build a framework where everybody is sailing in the same boat, supporting each other and taking care of what they’ve created. If they can see that, they’ll see why the translation is a more solid and less problematic project. On the other hand, if you don’t get this reaction, this game is over.

Preparing for the game

The time has come for the development teams to gather their ideas and start getting on the same page. This is a process that never needs to end and it changes depending on what stage of the project you are in. It’s always easier if you get to be one of the team’s first members and set the ground for the whole journey, but if you’re not, that doesn’t mean you can’t re-evaluate some previously taken decisions and change them for the better.

That said, assuming the team can get a foot in the door on day one, you’ll want to have this:

• A stack that has to be able to keep up with the requirements in an efficient way, and also be familiar or easy to learn to all the developers
• An architecture that will determine how all the pieces will be connected.
• A defined style guide that will make sure everyone is coding in the same fashion - the more detailed and rigid it is, the better, but at least have clean documentation with examples-.

Communication is everything at this stage. Creating spaces for open discussions about these topics will dictate the outcome of the decisions. Having that in mind, if you are not finding yourself in 2 hours-long meetings with a lot of back and forth, you might not be giving the discussion the importance that it needs.

Have all that sorted out and you will be ahead in the game. Although arriving at this scenario is not cheap at the beginning, having enough transparency around it, the PO will understand the impact this will have on the product, let alone the huge improvement you’ll be setting up for the devs’ experience throughout the project.

Mastering your code writing

Okay, time to type. But wait! There is only one question left to be answered, and it’s one you need to ask yourself: “How can I do this better?” That’s it, truthfully. If no one has the perfect answer, why not give it your shot?

There is no article, course, or degree that will get you further than questioning yourself. Only by challenging your convictions, you’ll grow. What’s more, I would strongly suggest using this question as a kick-off for digging into a source of new information. Instead of devouring 10 courses that you will forget before over a couple of beers, face the real world first, and go get what you need to survive in it.

The ultimate Battlefield: Code review

Working alongside other developers is a challenge on its own, let alone doing it in high-quality terms when being on the same page at all times is of extreme importance. Needless to say, here ignorance is not a valid consensus mechanism, which means that everyone is responsible for calling out any inconsistencies there may be with the best practices they have previously defined.

At this stage, it’s better to be annoying than silent. If you have to leave 20 comments in a single Pull Request, leave them, and yes, the field can get dirty sometimes, with strong contrasting technical opinions, different mindsets, and divergent priorities. Nevertheless, if done professionally, these are milestones towards building a shared concept of your work. Remember: questioning yourself is what will get you further, so apply that and bring your team with you.

There’s an internal and external purpose to this process. The internal purpose is that the PR under review is clean and matches the team’s standards (functionality and performance are a given for the entirety of this article). On the other hand, the external purpose is the overall vision of how that integration might be affecting the rest of the code, as well as a place for coming up with new ideas, re-evaluation of what you are doing, and most importantly, the opportunity to teach and learn from your teammates. Not because you need to move a ticket or achieve the sprint’s goal, but because you are growing together.

Loose the arrow: What to avoid

I have three very important pieces of advice for this final stage: Nock, draw, loose!

We’ve been talking about how to nock and draw the bow to shoot the perfect arrow throughout this post, yet you need to shoot at some time. In other words, you need to deliver value. In the end, that’s what we’re expected to do. Clients pay for results, not for how pretty our code is. Since that’s the case, you can’t be the enemy of the product. As perfection does not exist, flexibility is required.

With that said, let’s straighten this out:

There is a huge difference between taking a delivery-focused decision and cutting out corners.

Take note of that one. In this framework, if you have to rush a decision, its resulting code should be tracked as tech debt.

Don’t be ruthless

Even if your team is not keeping up with the established guidelines, you have to communicate in the most collaborative manner possible and try to understand them. For that reason, you also have to learn to define priorities to reach the objectives. If you have to make 20 comments on every PR you see, start by getting the core concepts right. Lowering the bar is not that dramatic as long as the team is always pushing to level up. A good idea for overcoming these challenges is to start adding tech debt in parallel with user stories to the sprint as the team gains experience.

Never think you know better, even if you might

You are part of a team, despite your seniority, knowledge of the project, or whatever advantage you may have over another teammate, so every meaningful decision you make has to be validated by them. Communicate as much as possible, ask for opinions and encourage them to give you feedback. A great benefit of the quality-focused mindset is the proactive approach it generates around every aspect of the project. If you get that part right, team bonding should increase progressively, creating a virtuous circle of mutual growth.

Conclusion

Hard work pays off, regardless of what you are doing. Crafting quality code is just one way more of trying to get the best out of the time you spend developing. You are undoubtedly setting your team up for an uphill battle, but you are preventing dreadful issues down the road.

Even if mistakes and wrong decisions jump the queue, you will notice them faster and take wiser actions. Plus, as the team strives to upgrade their technical game, that drive will lead to paying more attention to other project details, making room for greater involvement, exceeding average expectations, and enhancing the final product. In the end, you’ve won the battle.

Also Published here