DEV Community: Tower

2024's Git Survey is Live!

Bruno Brito — Thu, 24 Oct 2024 15:30:52 +0000

Git has become an indispensable tool for developers, not only to keep track of changes but also for collaboration. But how well do you really know this powerful tool? And what aspects could use some improvement? 🤔

We would love to know!

This is your chance to share your insights, experiences, and pain points with Git, whether you're a seasoned pro or just starting out. By participating in this survey, you'll not only contribute to a better understanding of how developers interact with Git, but you'll also help shape the future of Tower's Git client ☺️

As a token of appreciation for your time and valuable input, every participant will be automatically entered into a raffle to win one of ten $50 Amazon gift cards.

The survey is open now, and it only takes a few minutes to complete!

What's New in Tower 10

Bruno Brito — Wed, 02 Aug 2023 20:59:54 +0000

The much-anticipated version 10 of our Git client has been released, and it's our most colorful update yet.

Why? Because we've introduced Syntax Coloring to every file and diff view!

With support for nearly 200 languages, your Git repository's code is now more readable than ever! We also took the opportunity to add two other customization options that have been highly requested:

The possibility to show or hide invisible characters.
The ability to configure the preferred tab width (the default is 4).

It looks beautiful in dark mode, too! 😍

Tower's themes have also been fully updated to support the new Syntax Highlighting feature. That said, you can still modify them to your liking or create new ones from scratch.

You can download a 30-day trial for free to try it out! No registration or email is required.

P.S. This is the first of many exciting features that are on our roadmap for the upcoming months. Keep an eye out for what's to come! 🔥

Mac Developer Survey 2022 (with giveaway)

Julian Rothkamp — Thu, 10 Mar 2022 09:44:16 +0000

Get the chance to win some of the best Mac apps and developer tools by participating in the annual Mac Developer Survey! 🙌

Help us learn more about the Mac community, the most popular tools among developers, their preferred programming languages, and - most importantly - what kind of music they listen to while coding.

👉 Take the Mac Developer Survey 👈

We teamed up with some of the most popular apps and tools for developers and raffle over 100 prizes among all participants. Get a chance to win free licenses for Fantastical, Things, Pixelmator, Tower, ScraperAPI, Ulysses, Nova, Dash, TextExpander, Paw, MarsEdit, CleanShot X, Agenda, Alfred, DeployBot, Prerender, and many more.

The results of the survey will be published. If you are curious, you can check out last year's results and learn what apps and tools developers on the Mac prefer.

Who's behind the survey?
The survey is conducted by Tower - the team behind the best Git client for Mac and Windows. Learn more about how Tower enables you to easily undo mistakes in Git.

Mac Developer Survey

Julian Rothkamp — Wed, 10 Mar 2021 12:42:27 +0000

Are your curious about the state of the developer community on the Mac?

If you are working as a web or software developer on macOS, then you can help us find out by taking our short survey!

We will make the results publicly available.

To make the survey more fun, we teamed up with the best Mac apps and dev tools to give you the chance to win over 100 prizes.

Win free licenses for Sketch, 1Password, Things, Agenda, Nova, Ulysses, Paw, Alfred, TextExpander, Transmit, Little Snitch, Reveal, Marked, PaintCode, Soulver, Dash, Travis CI, Kaleidoscope, Tower and more!

App Design on macOS Big Sur

Kristian Lumme — Tue, 02 Mar 2021 17:49:44 +0000

In 2015, we covered the latest design changes in macOS on the Tower blog. At that point, OS X Yosemite had just been released, featuring a major overhaul of the user interface. Following in the footsteps of iOS, Yosemite moved away from a skeuomorphic interface towards a more flat, minimalistic design. At the same time, the Tower Git client was updated to adapt the new look and feel of OS X 10.10.

Well, the time is here again! macOS Big Sur has been released, and with it come comprehensive visual changes to the primary elements of the operating system, including windows, menus, icons and the dock. We’ve been hard at work making sure Tower feels right at home in this new environment. In this article, we’ll take a look at some of the design changes introduced in macOS Big Sur, and how we’ve applied these to Tower for Mac.

What motivates the changes to the user interface, and what is the long-term vision that drives and shapes these changes from version to version? Only Apple knows for sure. However, as spectators, we can certainly discern some overall trends. The Big Sur updates reflect some movements that have been going on for a long time.

Like OS X Yosemite, Big Sur seems to move in the direction of iOS visually. While it’s true that there’s more to macOS Big Sur than copying iOS, and while it may be more appropriate to say that the design of both iOS and macOS reflect the direction of the technology industry and of Apple as a whole, this statement does have a point. In an interview with MKBHD, Craig Federighi (Apple's senior vice president of Software Engineering) mentions the mental overhead required when constantly switching between the different interfaces of iOS and macOS. Making macOS feel more familiar for iOS-users reduces this overhead.

Apple has also been moving away from cluttered interfaces, towards sparseness and placing as much focus on content as possible. Whether you’re viewing photos, reading, or browsing your files, the content is featured prominently while available actions aren’t always immediately visible. With its increased spacing, reduced contrast and lighter icons, macOS Big Sur takes another step in this direction.

Changes in Big Sur

Having covered the general trends, let’s take a closer look at some of the visual updates in Big Sur! The look of windows is a good place to start. One of the essential elements of the user interface, windows receive some prominent changes:

Corners are more rounded than before.
Colors are lighter and contrast is decreased.
Increased spacing and more discreet icons contribute to the lightness of the interface.
Sidebars can now take up the whole height of the window.
The window title is integrated into the toolbar.

A Finder window in macOS Big Sur...

... and in Catalina.

An app can now specify an app-specific accent color, which is used for buttons, selections, and in sidebars. Selections have a new, rounded look, and many controls have been redesigned. Sheets have also been redesigned, now looking like modal popups, instead of folding down from the bottom edge of the toolbar.

Big Sur accent color, rounded selections...

... and a Big Sur sheet.

SF Symbols, a library of icons made by Apple previously available in iOS, is now included and used in macOS. These icons can be used in toolbars, sidebars and elsewhere.

App icons get a new style as well, with all icons now using a rounded rectangle shape. While the icons have been updated to correspond more closely to their iOS counterparts, they do retain some macOS touches. Traditionally, app icons in macOS have featured a more realistic style than in iOS, and many Big Sur icons sport quite a bit of detail.

Big Sur app icon design moving closer to iOS.

There are many more changes in macOS Big Sur than covered here. The dock is redesigned, as is the notification center, and there is a new control center (another change brought over from iOS). Menus look different, there are new system sounds, and more. In fact, along with the news of the switch to Apple Silicon — Apple-made processors — for Mac hardware, these changes were enough for Apple to decide to turn up the version number for macOS Big Sur to 11! Catalina, the previous version of macOS, has the version number 10.15, while macOS Big Sur is known as version 11.0.

Changes in Tower

If you ask us, part of what makes Tower great is the fact that it’s a native Mac app. Not only does this provide the best performance, but also the best integration with the operating system — the environment in which the app is used. As macOS users generally update quickly, it’s important that Tower adapts the design language of the latest macOS version. Of course, this can’t mean that Tower suddenly looks out-of-place on previous versions — while some changes can apply both to old and new macOS versions, some user interface changes should be restricted to users running the latest update. We’ve been hard at work updating Tower to take advantage of what macOS has to offer, and we think the result is a Git client that looks and feels better than ever!

At first glance, you’ll notice that Tower adapts the full-height sidebar look of macOS Big Sur. This change doesn’t only affect the sidebar: it has consequences for the toolbar, the window title and the navigation bar. The buttons in the toolbar, pushed to the right, now share space with the window title and with elements from the navigation bar, like the clone button. The navigation bar itself has been removed, for a cleaner look. The services and bookmarks icons, previously in the navigation bar, now show up in the main toolbar, at the top of the new full-height sidebar.

Tower 6 running on Big Sur...

... and on Catalina.

Big Sur comes with a new look for selections, with rounded corners and different spacing. Naturally, Tower adopts these, except for in some places where rounded selections wouldn't make visual sense.

Icons have been updated: we now use SF symbols along with some custom ones in the sidebar, the toolbar and in the quick actions popup. These icons have a lighter look than the ones previously used. In addition, the sidebar icons and selections now use the system accent color, so if you go into your macOS preferences and change the accent color, you’ll see your choice reflected in Tower’s sidebar.

A change which shows up on older macOS versions as well concerns the remote activity area. This area, showing ongoing pushes and fetches, for example, used to be visible all the time. Now, it only shows up when there are actual remote activities going on, otherwise, it stays out of the way.

Finally, our app icon now adapts the rounded-rectangle shape of other Big Sur apps.

Of course, this is just an overview. There are a lot of changes beyond the main ones described here. Positioning and spacing has been adjusted throughout the app, as have the colors of graph lines, badges and file statuses. The preferences window has been rewritten in order to facilitate easier updates and changes in the future. Tower has been recompiled and optimized for running on Apple Silicon. All in all, we are very happy with how Tower Big Sur turned out — we think this is the best-looking, most usable version of Tower yet!

9 Reasons Why Code Breaks

Tobias Günther — Tue, 16 Feb 2021 08:26:14 +0000

1. Code is Untested

Changing code in one place all too often breaks code in a (seemingly) unrelated place. No matter how experienced you might be: you won't be able to predict the possible side effects that code changes can have. That's what gives our jobs that "thrilling touch"...

Back your code with automated tests!

2. Code Does Not Report Errors

You won't easily become aware of all your application's problems: some will only surface in very rare circumstances or with seldom used features. Although you cannot prevent or foresee all problems, you should at least make sure you're made aware as they happen.

Use exception reporting mechanisms, e.g. through services like AppCenter or Airbrake.io.

3. Code Remains Isolated too Long

Developing and keeping unfinished code separate from your production code is a sign of good breeding. However, not keeping your feature code up-to-date with other important development in your project will cause problems. Because the later and less often you integrate your new code with the rest of your project, the higher the risk of things not being compatible.

Integrate often! Make continuous integration part of your development workflow.

4. Code is Developed in Isolation

"Mike is the only one who knows this part of the code." And as it stands, Mike just started his 6-week vacation in the Himalaya... When code is developed by a single person in isolation, that code is fully dependent on that person. Whenever the developer is on vacation, sick, or busy with other stuff, that critical bug can't be fixed or that feature can't be added.

Consider pair programming and/or regular code reviews to share "code ownership".

5. Code Solves Problems That Aren't There

Every piece of code solves a problem. And ideally, it should only solve a problem you have (or are very likely to have). Of course, an endless number of other problems can be imagined... but trying to solve them when you're not likely to actually have them will make your code more complex than necessary.

Make sure you don't overengineer. Keep things as simple as possible.

6. Code Reinvents the Wheel

Any time you're looking at a programming problem, chances are that someone else has had the same problem before. And if you're lucky, the problem has not only been solved in a good enough way - but the solution has also been published. In that case, trying to write this code yourself would be the classic reinvention of the wheel - and a waste of your precious time.

Keep your eyes open for good third-party libraries that have stood the test in other projects already.

7. Code Depends on too Many External Pieces

While external libraries can lighten your workload, they can (unfortunately) also bite you: when they introduce bugs, when they increase loading time, when their development is discontinued, when you simply have too many of them in your project to keep an overview...

Use third-party libraries only when you're convinced that they are of high quality - and you really need them.

8. Code is Not Actively Maintained

Code rots. It's a sad but true fact. While some parts in a project change and evolve, others are left behind. These parts become liabilities over time. For example, because framework features became obsolete; or because the new code's demands aren't satisfied anymore.

Schedule time for regular refactorings.

9. Code is Not Properly Version-Controlled

Although most teams nowadays use a version control system like Git, they often don't use its full potential! Git has much more to offer than just "commit, pull, and push". Learning the more advanced stuff (from Interactive Rebase to Git's many "undo" features) can improve the quality of a code base tremendously!

Go beyond the basics and learn to use the more advanced features of Git!

If you want to take No. 9 - your Git knowledge - to the next level, I have a couple of tips for you:

Learn version control with Git, a beginner-friendly online book.
First Aid Kit for Git, a series of short videos on how to undo mistakes.
Git Cheat Sheet, a nice overview of the most important commands.

How We Work on the Tower Git Client

Kristian Lumme — Tue, 02 Feb 2021 09:44:58 +0000

The team behind the Tower Git client has been fully remote since 2015. During this time, we've faced the challenges of getting things done without sharing an office, but we've also seen the benefits. Working on Tower and associated tasks like support, marketing and websites in a completely distributed team has given us ample opportunity to develop our culture, and we've come to a few insights about how to work effectively remotely. We've had a post on how we work in the pipeline for some time and, as current world circumstances are bringing discussion on remote work to the forefront, we figured this would be a good time to share some thoughts and tips.

Culture and Values

"The best way to find out if you can trust somebody is to trust them."
— Ernest Hemingway

Any discussion of our culture has to start with trust. Trusting the people on the team is the foundation of our other habits, from asynchronous communication to self-direction. Some managers freak out if they don’t micromanage people — they feel they're not in control. We don't want to work in an environment where people only do things because they fear the consequences if they don’t. Finding people that care about what they are doing and who take pride in the accomplishments of the team is of paramount importance.

The rest follows quite naturally from the foundation of trust. We’re a small company and everyone is welcome to contribute their ideas and comments when it comes to what to work on. Given agreement on the most important tasks to focus on at the moment, people are expected to manage their own time, attention and priorities.

As mentioned, we eschew the “always available” culture and do asynchronous communication for the most part — we want most time to be available for getting things done, not taken up by responding to communication or sitting in meetings. If there is a truly urgent problem that needs immediate attention — like the website being down — we switch channels, to phone for example. In a similar vein, we are “offline by default”. This doesn't mean that none of us are connected to the internet (though some ISPs would argue differently); rather, it means that our default mode is to be working away without the distraction of having to respond to everything that comes up, or having to appear to be “online”.

Finally, we stick to a forty-hour work week, expecting people to put in their focused time and then leave work behind for the day.

Setting Expectations

When it comes to culture, we find that setting expectations is important! We document our expectations and choose tools that reinforce them. Knowing, for example, that urgent problems will be communicated through an appropriate medium helps to encourage the default mode of asynchronous communication in day-to-day work. Most importantly, we try to live by our word. If everyone around you responds to all communication in three seconds flat, that's the culture, not whatever the document says. Finding that others embrace these principles makes you comfortable doing so as well.

Needless to say, we didn’t have everything figured out regarding distributed culture coming out of the gate. On the contrary, like probably every other company making the switch from co-located to remote work, we were stuck in our old ways to begin with. This included undocumented workflows, many all-hands meetings but no recurring formats, synchronous communication, and a lack of tools. The processes outlined here are something that we’ve developed through the years, and that we expect to continue developing in the future.

Tools and Software

“To the man who only has a hammer, everything he encounters begins to look like a nail.”
— Abraham Maslow

Technology is what allows us to implement remote work in the first place. Naturally, we use a large number of different services and applications, including but far from limited to Twist, email, GitHub, Asana, Zoom, Confluence, Calendly, and Google G Suite to get our work done.

What tools you use is not the most important thing, but you can choose tools that align with and reinforce your culture — or clash with it! As an example, though we’ve used Slack in the past, we now use Twist as a team chat tool. Twist does not show online/offline indicators or who has read a particular message. It does allow for organisation of topics and gives you control over who gets notified for a particular message. This alleviates the feeling that you need to respond right away and helps you find the important points in a discussion even at a later date.

Challenges

“With freedom comes responsibility.”
— Eleanor Roosevelt

When it comes to working together, not seeing each other in person can create friction in a variety of ways. Sharing and understanding current status, progress and any blockers takes deliberate communication. Through text communication or even video chats, communicating and reading emotional state can be hard. A comment that comes off as friendly or joking in person might come across as blunt in an email, and it’s hard to gauge if a person needs some support with what they’re doing or if they’re happily working away and best left alone for the moment. Learning to communicate effectively through text is a requirement — this may present a challenge, but may also cultivate clearer and more thoughtful communication.

Connecting People

In addition to the professional aspect, only meeting your colleagues through text communication, with the occasional video chat, can feel challenging on a personal level. In short, remote work can feel lonely! You may not be quite up-to-date on what’s happening in the life of the people you work with. We do a few things to alleviate this, including peer 1-on-1s and weekly check-ins... but the truth is that in a distributed team, you have to be deliberate about nourishing your personal connections outside work, as you’re not going to get quite the same personal contact on a daily basis that you would get in a co-located team.

Nevertheless, we do try to combat these issues by meeting in person three times per year (in non-COVID times, that is)! The get-togethers are great opportunities to get to know each other a little better, and we find that the better you know the people you work with, the easier communication becomes. When it comes to day-to-day communication, we also find that too much is better than too little. We try to be open about what’s going on in our lives and our work, including the challenges — not only does sharing these things with your peers feel good, but it also helps them understand where your mind is at.

Discipline

People have joined the team with varying amounts of remote-work experience. Regardless of at what point in your life you start working remotely, there is a learning phase. When working at a dedicated office, the start and end of your workday are naturally delineated and the environment provides some discipline by itself. When working from home, you quickly find that you need to learn that discipline, and that if you don’t set routines for yourself, there will be none. The routines help establish boundaries between work and life outside of it. As you’re largely your own manager, organizing your own time and tasks is a must.

If you have kids or other family members around, it may be difficult for them to understand that you are present but not available for interaction. Personal relationships may require more effort, as staying inside becomes easier. The same goes for physical movement — it’s easy to underestimate how much commuting to an office makes you move around but if you spend all day, every day on your couch, you’ll notice the difference!

Benefits

“You mind putting on some pants? I find it a little weird I have to ask twice.”
— Phil, The Hangover

The freedom of being able to choose where and when you work is a benefit to a degree which really can’t be overstated. Some people are more productive in the mornings, others in the evenings, and as our many team members with kids can attest to, being able to structure your day to give you lots of quality time with your family members is priceless! Having complete control over your working environment (well, apart from aforementioned kids…) is also very helpful. There’s also the benefit of not having a commute, which can save you a lot of time per day.

As previously mentioned, in our distributed team, you take on a lot of the responsibility for managing yourself and taking ownership of your projects. The responsibility can be challenging, but also communicates trust and inspires you to bring your best. Owning a project makes it more meaningful to you than if you were just handed task after task from someone else, without much say about which problems to solve and how to solve them.

People and Processes

With a co-located team, a company is limited to finding employees among those living in or willing to relocate to a specific area. Remote work greatly increases the available talent pool, as you’re basically looking for people from the whole world. In practice, time zones are a consideration, as it’s helpful to have a bit of everyone's workday overlap, but with some flexibility you still have a lot of places to choose from!

Working remotely also helps you document processes and decisions — simply because you have no other choice! This can bring clarity and thoughtfulness to processes. The fact that everything needs to be written down may feel like extra work initially, but very quickly, you find that it saves a great deal of effort. In addition, the documentation is immensely useful when onboarding new members of the team.

How about cost? Not necessarily, though this is a common perception; while not having an office is a cost saving in itself, the costs for travel and get-togethers along with some extra tooling for remote work add up so that reduced costs are not necessarily a benefit of being fully remote.

Final Words

A common theme among the challenges and benefits mentioned above is that remote work forces you to be deliberate about many things that happen by themselves in a co-located workspace. Routines and work/life boundaries must be constructed with intent. Communication, whether about work or something personal, takes effort and care. The same goes for personal connections, status updates and even exercise. However, having to think about these things explicitly sooner rather than later may also be very useful! Being intentional up-front instead of having processes and decisions “just happen” helps with clarity and with creating good habits, and may also make any problems apparent sooner. This way, many obstacles can be turned into assets.

That’s about it for this look at the way we work on Tower. Remote work certainly brings its challenges, but for us, this is still an amazing way to work. A culture based on trust reduces overhead and inspires everyone to take responsibility for moving things forward. Self-direction and self-motivation are a must, as are building routines, nourishing your personal connections outside work and taking care of your health.

If there’s some aspect of our work culture you’re interested in hearing more about, feel free to reach out — maybe there is material for another post looking at some topic in more detail.

Until next time, hope you are all staying safe and looking out for each other!

Become a Better Programmer: 5 Essential Methods at a Glance

Tobias Günther — Wed, 27 Jan 2021 08:35:21 +0000

1. Unit Testing

Why? Every programmer has experienced something like this: you change a bit of code in one corner, and in a (seemingly) unrelated corner, something breaks! The bitter truth is: both new and changed code will inevitably contain bugs. Use automated tests that help you keep old code stable.

Keep in mind: You can also go one step further and write tests before your actual code. This can give you a whole new perspective on how to approach problems!

Read more: XP on Unit Tests and Test-Driven Development

2. Code Review

Why? Code that is ever only seen by a single programmer in your team is dangerous code: if that person gets sick or leaves your team, no one knows how this piece of your software really works. Additionally, no matter how great and experienced that developer is: it might be that he overlooked something, implementing only the second best solution.

These problems can easily be avoided by always having team members approve each other's code. It's both a quality control as well as a means to create collective ownership of your project's code.

Keep in mind: If pair programming (see below) is already an integral part of your workflow, you might not need additional code reviews!

Read more: Code Review on the blogs of IBM and Jeff Atwood.

3. Pair Programming

Why? Pair programming is an ideal tool to share knowledge in a team. Having a junior and a senior developer sitting side-by-side is the best way for the junior to learn. And since teaching is a great way to sharpen your own skills, even the senior can benefit.

Keep in mind: Make sure that each person gets in front of the keyboard on a rotating basis. It shouldn't become a "I teach, you listen" event.

Read more: XP about Pair Programming, Martin Fowler on Pair Programming Misconceptions, WikiHow on Pair Programming

4. Keep it Simple

Why? Planning for the unlikely makes code unnecessarily complex. Don't try to foresee your project's requirements in two years from now - too many things can (and will) change! You would waste time on an overly complex solution for a problem that proves to be different than you thought.

Keep in mind: Keeping it simple shouldn't be confused with "quick and dirty". You still have to work thoroughly and carefully!

Read more: KISS on apache.org

5. Design Patterns

Why? At its core, most programming problems belong to one of only a few general categories. These general problems have already been solved thousands of times - and are well-documented in a couple of "design patterns". Step back from the problem in front of you. And you'll be able to apply a proven best practice instead of reinventing the wheel.

Keep in mind: Applying design patterns shouldn't become a religion. Sometimes, all that's really necessary are a few lines of simple code...

Read more: A classic design patterns book, A beginner's guide to design patterns on net.tutsplus.com

(Bonus) 6. Version Control with Git

Why? Git and version control are often underestimated: being proficient with Git has the power to make you a better programmer - and help you build a better code base!

Keep in mind: Git is about more than just "commit, push, pull". Take its many "undo" features and you'll quickly understand how helpful it can be!

Read more: A completely free online book on Learning version control with Git and the First Aid Kit, a series of short videos on how to undo mistakes in Git.

First Aid Kit for Git

Tobias Günther — Wed, 02 Dec 2020 08:49:22 +0000

Here's the good news: Git allows you to undo almost any mistake! 🤩
But the bad news is: You have to know the right commands & tools! 😩

To help you learn the various ways to save your neck, I've compiled a series of 17 short videos and a handy cheat sheet - free to download!

You'll learn how to...

...correct and fix your very last commit
...discard uncommitted changes in your working copy
...undo and revert an old commit
...return to a previous version of your project
...restore a deleted branch or commit
...deal with merge conflicts like a pro

Go ahead and download my "First Aid Kit for Git" for free and learn how to undo your mistakes like a Pro!

Our Development Philosophy - Part 2: Collaboration & Testing

Julian Rothkamp — Tue, 01 Dec 2020 09:55:02 +0000

There are lots of books about programming languages and frameworks - but only few resources that talk about "softer" topics like testing and collaboration. In larger projects, however, these topics can easily be make-or-break for your team's success!

We learned in countless situations within our own team how important these skills really are: very often when things went wrong, it had been due to a lack of testing and/or collaboration. Here are some things we've learned while growing Tower to serve more than 100,000 users.

All Code Belongs to the Team

Code is teamwork, not the work of any individual developer. This also means that none of the code you've written belongs to you – it belongs to the team! Looking at code in this way is helpful and liberating for a couple of reasons:

It doesn't have to go your way. After understanding that code always belongs to the team, it becomes obvious that we need to comply with coding standards and guidelines. Since it's not your code you can't just write it any way you fancy. It's a common code base, so common rules must be adhered.
This should also make you more tolerant when looking at your colleagues' code. You might instinctively think of all the ways you would have done it differently. But again: it doesn't have to go your way, but your team's way. This can help a lot in making you more open-minded towards other solutions and approaches.
Everything is your problem. When you spot a potential problem in the code, it doesn't really matter if it was your fault for not. Since all of the project's code belongs to the team – and you are part of this team – weak code from any source becomes your problem.
Contrast this to an atmosphere where people are detached from their teams and their shared code: "this is not my problem" is an attitude that will never produce great products.
You. You. You. This is a simple reminder of our responsibilities as software developers: You are responsible for writing code. Then, you are also responsible for making it shippable or production ready. And of course, you are responsible for fixing any problems with it.
In our own team, where we don't have a dedicated quality assurance team, this reminded us that developers are not only responsible for writing down lines of code – but also for the quality of that code. This responsibility is nothing that you can duck out of or hand over to someone else.

Sharing Knowledge with Code Reviews

Code reviews have a huge potential to lift your development team to new heights.

Most obviously, discussing code in a review session can lead to a better solution than the original developer had had on her own. Two minds working together on the same problem will always have the chance to produce higher quality code.

But other potential benefits of code reviews might be even more interesting. Shared ownership, for example, is crucial to reduce knowledge silos: whenever you find that only a single developer in your team knows a certain piece of code, you are at risk. Whenever this developer goes on holidays, gets sick, or maybe even leaves the company you'll be in trouble.
But even if none of these situations occur: the fact that your team doesn't seem to have a truly shared code base is already telling. Have a look at the previous section and you'll understand why.

Additionally, code reviews can solve the hairy problem of knowledge exchange. If, like most teams, you have a mixture of junior and senior developers, you will certainly want those junior developers to benefit from your experts' experience and knowledge. Code reviews are an excellent way to pass on knowledge in situations like these.

And to make the process worthwhile for both sides (juniors and seniors), make sure your senior developers understand that both parties – the student and the teacher – will learn something on the way!

Not Everything Needs Improvement

Since there is no such thing as a perfect solution, you could argue that everything can be improved. And you're probably right. But the interesting question is not if something can be improved – but rather if it's worthwhile to improve a certain part in your application.

We know where our own product, Tower, has its weak spots. And if time was infinite, we would probably polish and improve every single bit. But with time being a scarce resource for any team you will have to set priorities. If you don't, your product will not take the direction you want it to take - or it might very well take no direction at all.

Being able to responsibly ponder if or if not to improve something really is an art. It takes years of experience and, in the best case, even conscious training. Saying no to a lot of things is a prerequisite for achieving anything of worth.

True in life, and true in software development.

Ask Questions

When reading other people's code it's all too easy to assume that you would have done it better. On first encounter, this or that line might seem unnecessarily complex or even superfluous. And you might of course be right. But it's very hard to say because of one simple fact: you didn't actually write the code.

From our own experience, we know that even the simplest problem can really contain a surprising and infinite amount of complexity. Only when actually working on the problem – when picking it apart, thinking about possible solutions, side effects, etc. – will one be able to understand its scope.

Therefore, when coming across a piece of code that makes you suspicious, it's a great ground rule to assume a good amount of hidden complexity. From this point of view you can either dive deep into the code and try to understand it and the underlying problem – or you simply get into a conversation with your teammate(s) and ask some humble questions.

Software is Only Complete with Tests

Unit tests are sometimes regarded as the icing on the cake. More appropriately, however, they would be better described as the cake's base.

In smaller projects, you might get away without writing unit tests. In any project with just a slight amount of complexity, however, you will not. And, just as a side note, it's remarkable to see how many projects started simple and very soon became complex. So please don't act surprised.

There are indeed countless reasons why unit testing is essential for us:

Making big changes, safely and quickly. In every larger project, you will have to perform refactorings at some point. But refactoring code without a decent amount of unit tests in place is a very frustrating experience: While fixing something you will often and inevitably break something else. Unit tests let you know when this happens.
Releasing to the public, confidently. If your application is shipped to paying customers, not having a solid unit test coverage should make you shiver every time you make a release.
Better code through tests. Writing good tests is one of the best preconditions to have good code in the end. This is because tests help you understand the problem you're trying to solve and create a simple, modular architecture.
Up-to-date documentation. In an ideal world, every important part of an application would be nicely documented. We would have wonderful, clean, and beautifully formatted documents that are a joy to read. And most importantly, we would update the documentation every time something in the code changes. Well... this is of course a fairytale. But having up to date documentation in general does not have to be a fairytale: unit tests can serve this purpose. Although probably not as pleasant to read as dedicated documentation, they are (almost by definition) always up to date. This makes unit tests a very valuable and reliable source of documentation.

Good test quality and good test coverage of important code parts are mandatory for larger projects. It made us much more confident that we would always be able to deliver Tower with a high quality and that we would always be able to make changes (big and small) safely and effectively.

Tests Make Development Faster

At first glance, using a test-driven approach would seem to be time-consuming and slow down your progress. And indeed, writing good unit tests takes time.

But over time, you will find that unit testing will in fact make you faster! For one thing, after thinking about your code design while writing a test, you will need less time to write the actual implementation code. You will have done a lot of the heavy lifting already by writing the tests.

The other benefit that will make you a lot more effective in the long run is stability: the likelihood of breaking existing code when making changes is significantly reduced through tests. You will save countless hours of bug hunting that you can now invest in something more useful.

Fixing by Testing

Bug fixing should be inseparably connected with writing tests. Of course you could just track that bloody animal down and simply fix the code. However, I guess that a lot of you are painfully familiar with the term "regression": the annoying re-emergence of a bug that you were so confident to have fixed.

If you want to make sure (and you should!) that a bug is fixed for good, there is only on proven way - by writing a test to safeguard this piece of code.

Test Low-Level Components

While producing a software product that is in daily use by almost 100,000 people, we learned a lot about errors. For one thing, we learned that they are an inevitable part of the business; especially with the diverse and complex system setups that Tower has to deal with, you cannot rule out and safeguard everything. But for another thing, we also learned where errors mostly occured.

In Tower (and most likely in a lot of other larger applications), most errors tend to occur in low level components. The good thing about this is that such components lend themselves very well to unit testing. In this area, a test-driven approach offers a huge chance to improve your application's overall stability and quality with a reasonable investment – by thoroughly testing low-level components.

Efficient Testing

In general, having a large amount of your code covered by unit tests is a good thing. However, if you ever hear a software developer brag about his "100% test coverage", you should be wary. Testing every single line of your application code might sound like something to strive for - but it really isn't!

On the one hand, this would of course afford an infinite amount of time. Much more importantly, however, there is in fact something like writing too many tests! At the latest, you will learn this when making a bigger refectoring: not only your code, but also your tests have to be maintained. When your code changes, your tests need to change, too.

The crucial criteria is value. Does the test bring you enough value to justify writing it? Typically, tests are of low value if they test only very simple logic. In these cases, the burden of having to maintain the test outweighs the little value that it brings.

Writing tests efficiently, then, means preferring fewer high-value tests over many low value tests.

Test, Don't Run

Manually testing a certain scenario in your application can really take a huge amount of time: you have to start the app, navigate your way to a certain view, and perform various additional actions to reproduce a certain scenario.

Writing a unit test for a scenario will indeed afford some time initially. But very quickly, probably already after having to test this only a couple of times, running the test will be much faster than starting the whole application and testing your way through it manually.

Besides being faster, however, the test will also provide better results in terms of quality and stability. In most cases, the initial effort is worth the long time benefits.

Writing Code is Only Half the Battle

If you've read this far, I hope you agree with me: becoming a great software developer takes more than just writing code. From testing to documentation and from ownership to communication, there's a lot to learn if you want to master the art of programming.

Be sure to join our free newsletter for more insights and advice on this exciting journey!

Understanding the Concept of Branches in Git

Tobias Günther — Thu, 26 Nov 2020 07:47:13 +0000

Using branches in your day-to-day work might very well prove to make you a better programmer or designer. Be that as it may, it's definitely one of the main reasons why Git is so highly respected. And although desktop GUIs like "Tower" make all of this a lot easier, it still makes sense to have a firm understanding of the underlying concepts!

First of all, if you're coming from another version control system, I kindly ask you to forget the things you already know about branching & merging. It's true that Git hasn't invented this particular wheel: many other VCS also offer branching. However, Git's concepts in this area are absolutely unique when it comes to ease of use and performance.

Now, let's look at why branches are so important.

Working in Contexts

In every project, there are always multiple different contexts where work happens. Each feature, bugfix, experiment, or alternative of your product is actually a context of its own: it can be seen as its own "topic", clearly separated from other topics.

This leaves you with an unlimited amount of different contexts. Most likely, you'll have at least one context for your "main" or "production" state, and another context for each feature, bugfix, experiment, etc.

In real-world projects, work always happens in multiple of these contexts in parallel:

While you're preparing 2 new variations of your website's design (context 1 & 2)...
you're also trying to fix an annoying bug (context 3).
Besides, you also update some content on your FAQ pages (context 4), while...
your teammate is working on a new feature for your shopping cart (context 5),...
and another colleague is experimenting with a whole new login functionality (context 6).

A World Without Branches

Not working in clearly separated contexts can (and sooner or later will) cause several problems:

What happens if your client likes variation 2 of the new design? In the meantime, a host of other changes have happened! How do you launch the new design while integrating all these other changes instead of losing them?
What happens if the shopping cart feature became obsolete because the client changed his mind? How do you get all that unwanted code (and only that code!) out?
What do you do if that new login functionality proves to be impossible to implement? It's already mingled with all of those other changes, being almost impossible to separate out!
How can you avoid losing track? Most likely, you shouldn't be bothered with all the topics from all of your colleagues. Things will start to get very confusing when you try to handle multiple topics in a single context:

A tempting workaround might be to simply copy your complete project folder for each new context. But this only leaves you with other problems:

You circumvent your VCS, since those new folders won't be under version control.
Not being version controlled, you can't easily share & collaborate with others.
Integrating changes from one context into another (maybe your main context) is difficult and error-prone.

To make a long story short: if your goal is to work professionally, you'll have to find a way to deal with multiple contexts in a professional manner.

Branches to the Rescue

You might have already guessed it: branches are what we need to solve these problems. Because a branch represents exactly such a context in a project and helps you keep it separate from all other contexts.

This was an excerpt from my (completely free!!) online book "Learn Version Control with Git". Feel free to read more if you want to understand How branches can solve these problems, How to create and manage them, How to integrate changes between branches and where remote branches come into play.

Our Development Philosophy - Part 1: Architecture, Design Patterns and Programming Principles

Julian Rothkamp — Wed, 25 Nov 2020 06:59:22 +0000

When software projects become bigger and more complex, you might reach a tipping point: one day, code quality becomes paramount. You can get away with easy fixes and a "quick & dirty" mindset in smaller projects. But as soon as complexity increases, you'll begin to feel sorry for every compromise you've made so far.

We've certainly experienced these growing pains in our own journey - with Tower steadily growing to now serve 100,000 developers and designers. This post talks about some of the important things we've learned along the way.

By the way: Part 2 of this series will soon follow. Be sure to join our newsletter to be notified.

Applications Need Solid Foundations

Building even the smallest of software applications is a major investment for most companies. Your team will spend days, weeks, months, and maybe even years building that application. But not only is this a huge one-time investment - you'll have to continue to put time and effort into it over its complete lifetime. Neither the coding nor the investment will stop when the application launches.

Let's take our own product Tower as an example: we had worked for 12 months to develop version 1.0 and bring it to market. But in the six years since then, we have produced many times more code than the original product contained.
This constant, never-ending maintenance and extension of an application means that its foundation becomes crucial. Much like with a house, it's not a clever idea to save some money by building just a cheap foundation.

Logically, one of our biggest goals is to make extending and improving that application as easy and safe as possible. This is where application architecture comes into play.

Only a really good architecture will help us protect the huge investment that building an application means. We will explore in greater depth what "good" architecture means (in our humble opinion). But the main qualities you'll want to aim for are the same timeless classics in every project: solidity, maintainability, extensibility and scalability.

Improving and refactoring an app's architecture will often seem like luxury - or maybe even like wasted time. But in reality, it should better be seen as a necessity, as a crucial and one of the most important duties of an experienced software engineer.

When we ask ourselves if we should invest into architectural improvements, the answer is usually yes.

Choosing the Boring Solution

When solving a complex problem, it's sometimes very tempting to choose an extraordinary solution. Not only will this solve the problem - but it will also impress your teammates and bring you everlasting glory. 🦄

An even better solution, however, would probably be a boring one. One that is easy to understand, even for your junior colleagues. One that is well-known on your platform and language. One that is absolutely not extraordinary.

Using such a boring solution means that you're using simple vocabulary, which greatly increases the chances of everybody understanding you. This will make it a lot easier for everybody to follow along - including new team members (and yourself, a couple of weeks after you've written that code).

When in doubt, go with the boring solution.

Coding the Lego Way

Trick question: if you had both modeling clay and Lego bricks available, what would you choose for building your application? Let's say you went with the modeling clay: pretty easy to shape, bright colors, strawberry taste - what more could you want? But the problems are inevitable as soon as you want to correct, extend, or improve something you've already built. There is no way to easily separate individual parts after you've mixed and mingled them.

If you've chosen Lego bricks, on the other hand, subsequent changes are easy: the yellow "authentication" block isn't big enough? Just take it out and replace it with a bigger one. The green "export format" block needs to be extended with a PDF option? Just put an additional light green brick next to it.

Modularity, the concept that the Lego bricks symbolize, is synonymous with extensibility, maintainability and longevity of your application. No matter which framework, language, or programming principle you prefer: always shoot for modularity in your code!

Aiming for Simplicity

Acronyms FTW! Car enthusiasts might now think of BMW, but software developers should think of KISS and YAGNI.

"Keep it simple, stupid" should remind us that the simple solution will always beat the overengineered solution. The reasons why this is true are almost endless. And they might be easier to understand when looking at the opposite: complex code.

Complex code is a perfect hiding place for mistakes.
Complex code is hard to understand, for your coworkers and yourself.
Complex code cannot easily be extended.
Complex code cannot be reused. And, last but certainly not least, writing complex code will cause your teammates to brand you as an outlaw.

When a simpler solution seems sufficient right now, you should always aim for it.

When you realize that your solution isn't really necessary at all, you should drop it. This is what YAGNI is about - "You ain't gonna need it" reminds us to stay modest when planning the volume and scope of our implementations. Will users really need this feature? Will they need this option within a feature? These questions of course will translate to our code: will we really need that class / module / routine?

Constantly Redefining the Term "Edge Case"

This point might not apply to every application in the same extent. But with Tower being used by over 100,000 people worldwide, we constantly had to redefine the term "edge case" for us.

If your application serves a large user base, you will inevitably have to be more thorough when thinking about how people will use it. Things that rarely occur with a thousand users might become a daily event for 100,000 users.

This makes defining the term "edge case" a very individual matter: each and every team has to define for themselves what they consider an edge case. Also, be prepared to constantly redefine this term as your user base grows: Your current edge cases become too common to qualify for that label; and, at the same time, new edge cases will appear.

It pays off to invest a little more time thinking about these things before jumping into implementation. This way, you can include graceful handling of these cases already when writing the original implementation. This is much easier than having to catch up on it a couple of weeks later - when both your memory of the problem isn't fresh anymore and when the innocent little edge case has somehow turned out to be a full-blown bug.

Creating Good APIs

I'm sure you've used a third-party API at some point in your dev career - for example to create new contacts in your CRM, to send emails through a newsletter service, or to virtually do anything else with a third-party service.

If you've interacted with a couple such APIs, you will certainly have noticed some differences between them: using one was probably more pleasant than the other. It's easy to notice which API was designed thoroughly, by an experienced developer, and probably with a lot of effort and thought. And it's just as easy to be frustrated with an API that was designed in a poor and sloppy way. The former was probably a joy to use, while the latter was probably... not.

Since the effects are so obvious, most developers tend to quickly agree that it's almost a duty to design public APIs in a careful and thought-out way. Nobody wants to work with a crappy API - and nobody wants to burden other developers with using their API being crappy.

Modern software design puts great emphasis on the concept of "application programming interfaces". However, as most developers already know, the concept goes a lot deeper and is not exclusive to a public interface. Instead, you should build APIs inside your application, for internal use, too.

Approaching these internal APIs in exactly the same way you'd create a public one can make a huge difference: your colleagues (and you) will want to interact with this part of your application. Making the interaction as easy as possible for these people is one of the best goals you can have.

An easy, thoughtful API is probably the part of your software where quality matters the most. Your colleagues might forgive you a little sloppiness in the internals of this or that method. But they won't (and shouldn't) forgive you for creating a bad API.

Design Patterns

Sometimes, a solution is so beautiful, you wish you had the right problem to apply it to. But unfortunately, problems come first. As beautiful as your new screwdriver may be (imagine a handle made of gold, with your initials engraved, of course...), if the problem at hand is to knock in a nail, it makes for only a less than perfect solution.

Now, after teaching you all I know about manual craft, let's return to software development - and consider "design patterns" as your toolbox. Every design pattern you know (and understand) is an instrument in your toolbox. It's certainly great to have many of them!

The problems start, however, as soon as you let the patterns dictate your coding. They should be there to support you, to propose a proven solution - for the right problem! Programming paradigms should be used where they fit and not be enforced. Your components should be designed with your application's requirements in mind - not with a beautiful design pattern.

In cases where you've indeed found a helpful pattern for your current problem, there's only one more thing: be sure to really understand the pattern and its consequences on your coding.

Embrace Best Practices

It's hard to find a programming problem that hasn't been solved by someone else already. And still, developers around the world are reinventing the wheel countless times, every day. I think it's a mixture of different things that encourages people to do this:

"I hate having 400 third-party libraries in my project." - Absolutely understandable, no one would love this. The thing is: when I'm talking about "solved problems", such a proven solution doesn't necessarily have to take the form of ready-made code. It could also be a mere concept, a design pattern, or simply a discussion with the guy next door that you know has solved something similar. Solutions can take many forms - so don't limit yourself to just "libraries" and other forms of "complete" solutions.
"It's just a small probem. I'll have my own solution in no time." - Every developer with more than a single day of experience has learned a very valuable lesson: Problems are (almost always!) more complex than they first seem. Experienced developers will have learned another lesson: Even with growing experience, it's still somewhere between hard and impossible to see all of the potential complexities that a problem contains. Put simply: we are prone to underestimate problems, again and again.
All of this means that we should thoroughly evaluate if the problem at hand really has to be solved by you on your own.
"I don't like the existing solutions. I can create something better." - This could very well be another form of underestimation. Especially if a solution has been around for a while and used in many projects, you should thorougly check if your evaluation of that solution being bad is really correct. Again, we often tend to underestimate the complexities that hide in even the simplest problems. There's also another dimension to this topic: if the solution we're talking about is a commonly agreed way to handle such a problem - either in your team or on your technical platform - then you should again think twice before you go your very own way. The very least you should do is discuss your objections with your teammates.

All of this means that "best practices" - in the form of proven concepts, conventions, patterns, and high-quality libraries - should always be your first point of reference. After carefully verifying that those best practices aren't suitable for your special case, you're free to go your own way.

Fashion-Driven Development

Just for a moment, please imagine we'd be stuck in the eighties: we'd be stuck with rotary phones, flared pants, and terrible haircuts. What an unsettling idea...
But thankfully, the world has evolved: technical (and fashionable) advancements have made things possible that weren't possible before. New technology has enabled us to create new things.

But what about "old" technology? What about the software frameworks and libraries that were created yesterday? Are they, as a natural consequence, yesterday's news?

In many fields, especially on the web, it's easy to get this impression: the newer the framework, the better it must be. Everything that was created last week is automatically inferior and, by all means, should be abandoned. But by following every new trend, we chicken out of the hard work to improve the things we already have - and miss out on a lot of quality.

Quality takes time. A piece of software that is new hasn't reached its peak, yet. It cannot. It will inevitably contain bugs and other problems that one can only hope to correct with time and lots of hard work. New technology, therefore, isn't always better technology.
Quality needs collaboration. If, over time, we also seek the advice and feedback of others, we can harness another chance to make better software. Note that "collaboration" in this sense can come in many forms: as feedback and direct contributions, but also simply in the form of usage and trial, e.g. when a library is included in many real-world projects.
Quality grows out of failure. New things haven't been given the chance to fail, yet. Technology is no exception to this rule: you have to show me perfect code that was written on the first go. Software must have failed and been improved before it can be regarded to be mature.

While diving into new technology is important, we need to keep an eye on the criteria we use to evaluate it. Novelty isn't the exciting criteria - but usefulness is. New technology needs to provide actual value over existing solutions.

We don't have to throw older, proven technologies out of the window the same moment we discover something new. Make sure you understand both the old technology and the new one before buying into the next new thing.

Stack-Overflow-Driven Development

Thank God for StackOverflow.com. I seriously can't imagine my (programming) life without it. And with it being one of the most visited sites on the web, I guess I'm not alone.

There's a long friendship between me and Stack Overflow. It helped me countless times when I was stuck on a problem. It gave me an idea of how other people had approached the same problem. Sometimes these other people helped me solve my problem. Sometimes they gave me a hint for a possible solution. And sometimes reading their problems at least let me know that I wasn't alone with a miserable bug...

After hours or even days of searching and trying different things, your shields are down. You are crawling through your code on all fours like a man who's lost in the desert. But all of a sudden your search is successful! Eureka! Searching Stack Overflow has finally yielded a piece of code that works!

That's when you have to watch out and resist the temptation to take code that works for code that's good. What you've found on Stack Overflow is - in all but the rarest cases - not a solution but rather a clue. It can certainly make for a great pointer, but it was not written with your exact problem / requirements / constraints /code base / application in mind. And sometimes, it might simply be a dirty hack.

Embrace Stack Overflow as a good source of guidance for certain problems. But also take the time to thoroughly and honestly evaluate if you've found a real, solid solution.

Next Up: Collaboration & Testing

In the second part of this series, we'll talk about collaboration and testing. Be sure to join our newsletter to make sure you don't miss it!