As the clock winds down on 2016, there’s a growing emphasis for 2017 and the years to follow. And that emphasis is on the importance for knowledge workers to be able to focus in order to do their best work. The tool sets and work environments of the modern “office worker” are maximized for distraction, not for in-depth output. How can teams — big or small — ensure they’re set to be successful by consistently cranking out great work?
In his book Deep Work, Cal Newport makes the case that the people who learn to minimize distractions and increase their ability to focus for long stretches will be the most successful in the decades to come. He lists what he believes are the two core qualities required in order to thrive in the coming years:
The ability to quickly master hard things.
The ability to produce at an elite level, in terms of both quality and speed.
And the key to growing these abilities is to learn to work deeply. What is “Deep Work”? According to Newport, this type of work would be defined as:
> Professional activities performed in a state of distraction-free concentration that push your cognitive abilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.
And his end hypothesis is that this skill is becoming both more important and increasingly rare in our current economy, and those who master it will thrive. As a software engineer himself, Newport understands the importance. This quote from Rands nails it:
> If you’re a software engineer, your craft is code and you’re at maximum productivity when you have long uninterrupted minutes and each unexpected visual and auditory interruption is a unique opportunity to completely lose your train of thoughts, context, and hard to recover mental momentum.
How about your team? Do your designers, developers, and teammates in all roles feel that they’re able to do their very best, day in and day out? From our experience, that is not the case for many.
Early in 2016, I spent time doing in-depth interviews with 30 or so Beanstalk customers. When asked what the biggest pain point was, the following comment sums up a common sentiment:
> Keeping on top of things (Slack, bots, Beanstalk, Basecamp, Zendesk) is taking more and more time, especially since I wear so many hats on the team. Having multiple tools to manage projects and client communication leads to feeling burnt out. There is a desire to find tools that keep things all in one place.
From what we’ve heard, achieving focus is a difficulty more most teams. If you’re building a product or servicing clients, how can you improve in this area?
At Wildbit, we think about this a lot and having taken many of the following steps.
Establish the culture
First, making any improvements in this area will be very hard if there’s no buy-in from your team at large. Having half of a team attempt to focus while the other half is responding to every email as they arrive, sending DM’s without thought, or stopping by the office or cubicle for any question is sure to lead to failure. While it is possible to make some small changes to your own habits, you’ll benefit far more — and experience less frustration — when this is a team effort.
And (hopefully) it starts at the top. Newport advocates for knowledge workers to sell their employers/managers on this entire concept. And here at Wildbit, we’re fortunate to have founders who understand the importance of doing our best (there’s a reason we have values like this highlighted on our site). When the suggestion was made early in 2016, our co-founder Natalie read Deep Work herself. And it had such an impact that focus was a key theme for our annual team retreat in 2016.
Focus is important enough that the new Wildbit office was designed with this in mind. Designers, developers, product managers, marketers, and writers … we all need quiet and solitude to focus on our tasks in order to product our best work.
And this is not something that is fixed once, then you’re set. In a recent town hall meeting, Natalie shared that it felt like as a team we were slipping back into old habits. This time around, she asked the entire team to read Deep Work so we’re all on the same page and reinforcing the practices.
In order to have some success with a culture of this sort, the entire team should follow the practices.
Choose the right tools
Once a team has established what is important to them, you can start to look for the tools that can support your priorities. And when it comes to working as a remote team, this requires tools that allow for communication without distraction. As the Internet matures, it’s becoming more clear that how we communicate affects our work and how we feel. As Jason Fried mentions in Is group chat making you sweat?:
> We’ve also seen strong evidence that the method and manner in which you choose to communicate has a major influence on how people feel at work. Frazzled, exhausted, and anxious? Or calm, cool, and collected? These aren’t just states of mind, they are conditions caused by the kinds of tools we use, and the kinds of behaviors those tools encourage.
As with many other teams, Wildbit uses a combination of Slack and Basecamp to achieve the goal of communication with minimal distraction. Both services include settings that enable us to keep up to speed on projects and activities related to our work (as well as build bonds with teammates), but without a constant disruption during the workday.
Slack allows you to set yourself to DND (do not disturb), while Basecamp includes several related settings (latest activity, reports, email summaries, notifications, and work can wait. And we’re all encouraged to turn off notifications, quit our communications tools, and even work away from our computers (example: we are all agreed to never use the @here qualifier in our product channels, instead mentioning specific people with their unique handles).
However, the tools are only as good as the resolve of the person sitting in the chair. You twist all the knobs and pull all the levers to minimize distractions, then sabotage your efforts by “checking in” manually. This is why the culture is the foundation for doing consistent, focused work.
Build habits and routines
Last, each individual contributor on a team can help themselves do their best work by creating routines that build habits. After, all the end results of our lives are built on the little things we do with regularity. Or, as John Maxwell puts it:
> You will never change your life until you change something you do daily. The secret of your success is found in your daily routine.
At Wildbit, this comes out in different ways for people in various roles.
Artem, one of our developers, has a strict routine for doing focused work, yet still make time to give advanced support to our customers. Each day, he does his project/feature work that requires depth and focus first. Then, he ends each day cleaning out his support queue.
This allows him to use his highest levels of energy on the things that will move our products forward and helping in customers in the long run. But he also gives fantastic support to our customers right now, consistently. And that consistency wins him a lot of brownie points with our customer success team: we know we can count on him following this routine, which helps us provide better support as well.
Another example is our customer success team. With 5 people supporting 3 products, we split our time between proactive success efforts and reactive support efforts. Providing top notch customer support has always been highly valued at Wildbit, but being in the inbox all day can make it hard to focus on a larger initiative.
To ensure that everyone makes the most of their success time, we take entire days to work on success related items. Even further, we try to schedule our focus days back to back so there is less attention residue from the support given in the previous day.
Putting little steps in place can have a big impact over time.
Cultivating an environment that both values focus and produce great work is not an easy task. But it’s a vital one. Most of us are figuring it out as we go, wading through the tools, processes, and sources of entertainment that fragment our attention. Making change in this area requires proactive efforts.
The details above cover some of how we’re achieving this here at Wildbit. If you and your team have fought the same battle, we’d love to hear what’s worked for you. Let us know!
Our good friends at Tower have an exciting announcement. Their excellent Git client for macOS is now available for Windows! It’s written natively with stability and performance in mind. This brings all the great features from their macOS client to Windows.
Tower integrates with Beanstalk, allowing you to connect your Beanstalk account and create branches, new remote repositories, and more all from the app. Reverting a commit is as simple as right-clicking on a commit and selecting “Revert …” to roll back. If a merge has a conflict, it’s simple to resolve with Tower’s Conflict Wizard. And stashing and fetching is automatic with Tower.
If you’re a Git novice, Tower has you covered with extensive documentation, video tutorials, and an ebook. And if you’re a Git expert Tower includes great features you’ll love like support for git-flow and submodules.
We’re excited that our Windows customers can experience what an excellent Git client Tower is!
If you work in web development, you know how difficult it is to change from one tool to another. It can disrupt your workflow, and adjusting can be an uncomfortable and painful experience.
On top of that, there’s a learning curve involved to get teammates up to speed with the new way of doing things. And if the adjustment is unbearable, you may find yourself wondering, “Was this change really worth the hassle?”
Change can be difficult, especially in the tech industry. But without being open to the idea, you could miss out on new innovations that’ll make doing your job easier.
That’s what we’re about at Wildbit. Today we’re going to talk about how Git brings you one step closer to doing just that.
Most experienced developers know the importance of version control.
But this article will highlight the benefits of Git, and how to help your team transition to it.
First, let’s discuss what makes Git different from other VCS like Subversion.
What makes Git different?
Git is a distributed VCS, while SVN is a centralized system based on CVS. Centralized means that there is a single repository on a remote server that all team members work on. The centralized server stores code updates and, as long as that server is online, the code is accessible.
Git uses a different approach from CVS and Subversion in that it uses the peer-to-peer model. Unlike SVN, Git allows you to base your repository on one or more remote repositories instead of a central location.
You can also publish your repository for other developers to access or clone if needed. This makes Git great if you’re on a distributed team, or work on open source projects.
If your SVN server goes down, there’s reason to panic. But with a Git repository, your colleagues can work with confidence, knowing they can still work on the repository locally. This saves you time, and worry when connection issues arise.
But that’s not the only advantage Git offers.
The benefits of Git
One way to help your team transition is to focus on the benefits of the change. It won’t be easy, but focusing on the advantages of Git will give your team something to look forward to.
Here are a few of many benefits of Git that’ll hopefully peak the interest of your team.
Branching made easy
Branching with Subversion can be a lot of work. First, you have to create a copy of your project tree in your repository using the svn copy command. This command creates a copy of your project in a new folder or directory. And you have to do this each time you want to create a new branch.
In Git, branches are pointers to a specific revision. There’s no need to create separate directories for each branch, Git takes care of that in a few keystrokes. Let’s think about what this all means for a moment.
Think about how long it takes to create or merge a branch with SVN. If you’ve asked yourself, “Why is SVN taking so long to run a simple command?” then this is one benefit that you’ll appreciate.
Git is fast, and most operations on Git take place on your local disk. This makes branching and merging happen almost instantly. No more waiting for commands to complete.
To add, branches are relative to the repo you’re working with. Remember, in SVN there is one central repository. But Git allows you to have several remote repositories, and host a repository locally.
Each remote repository can have its own set of branches, with it’s own unique purposes. This means if you want to experiment with your repository, you can create a branch in your local copy and test your code without exposing it to the rest of your team.
The staging area
Git gives you the ability to handpick the files you want to commit. SVN commits all changed files to your central repository when modified. Git does not work this way. Let’s say you made changes to two files, let’s call them File A and File B.
You’re ready to commit File A, but you want to check with a colleague before committing File B. How do you save the changes made to File B and still commit File A?
You can use the staging area as a holding place for files you’ve modified, but do not want to commit yet. For more information on how to use the staging area, check out our “Getting Started with Git” guide.
Ability to work offline
Another stark contrast is that Git allows you to get work done without an internet connection.
What happens if you’re wrapping up your work day, and you lose connection to the internet, or your corporate VPN is down? If you’re using SVN, you’ll be in a tough spot. But Git allows you to work uninterrupted by recording commits in your local repository. This means you don’t have to push changes to your remote repo until you’re ready to do so.
Workflow flexibility
Git will work with almost any workflow, and this includes a centralized workflow. While Git does not need a centralized server, you can sync with other Git repositories. This allows you to add multiple remote repositories to your project, and push and pull changes between them.
You can also use the “read” and “write” permissions to set restrictions on your project. This gives you ultimate flexibility when choosing your workflow.
Helping your team transition
Communicate
Don’t blindside your colleagues. Do yourself a favor and communicate your plans to transition as early as possible.
This allows them to examine what’s needed before making the switched. If you have any who oppose the idea, why not share with them the advantages Git offers? This is also a good time to answer a few key questions such as:
“How and when do we want to move to Git?”
“How long do we want this process to take?”
Educate
Whether you have a team of Git experts, or newbies — you want to get everyone on the same page.
Educating your team goes beyond teaching them simple Git commands, but it also involves establishing a workflow. Or at least, starting a discussion about it.
Trying to figure out the best workflow after you’ve transitioned your repos to Git can be a recipe for disaster.
It’s also worthwhile to understand how to integrate git with other tools you use. Why not take a day or two to hack out these details with your team?
Educate your team on what it takes to get started with git, and how creating and comparing branches can help avoid coding mistakes before they happen.
Implement
The last step in this process is to put what you’ve learned into practice. You could start by converting one of your repos to Git. This gives your team the opportunity to get comfortable running Git commands, or using a new client.
Remember to be patient with yourself and your colleagues during this time. You will make mistakes when learning a new system, but the payoff will be worth it.
Making the transition to Git isn’t a walk in the park. And it isn’t for everyone. But these are a few of the many benefits it offers.
If you’ve thought about making the switch for a while, consider what’s preventing you from finalizing the move.
If you work on a distributed team, and want to improve your branching process, Git may be a change worth making. If you don’t have any VCS in place, Git could be a good place to start.
You’ll save much time and energy you save investing in Git.
Over the last few months on the Beanstalk blog we’ve been covering best practices from commit messages to deployment processes, and to branch management. We thought this would be a good time to look at how to extend Beanstalk and improve your productivity.
There are three different ways to extend Beanstalk. The first is integrating your repository with other web apps. Our integration page highlights some of the possibilities. The other two ways come from webhooks and the Beanstalk API. Both of these allow anyone to extend Beanstalk.
Integration
Need to keep a colleague in the loop, but they don’t need Beanstalk access? Integration is the perfect solution.
Built by the Beanstalk team, an integration connects Beanstalk to other web apps. These fit around three different themes: Issue Tracking/Project Management, Time Tracking, and Team Discussion. They help you tie commits to issues and support cases or track time spent on the new flagship feature.
Integrations are on the repository level. To enable and explore integrations available, navigate to repository settings and click on “Integration”.
Some of the possibilities available:
Track time you spent on a commit and send that information to Harvest.
After triggering a deployment, Beanstalk will post to a Slack channel.
Tie your commit to a JIRA issue and assign the issue to another team member. The commit in Beanstalk will also link to the JIRA issue.
Here’s what a commit message posting time to Harvest would look like:
Adjusted header logo position [time:30m task:webdev]
This is what is looks like if you assigned a JIRA issue to a colleague via commit message:
Updated footer wording [#007 assign:John]
Webhooks
Sending data from Beanstalk to another web service is a snap with webhooks. Support is available for both modular and classic webhooks. Like an integration, webhooks can be set-up in the “Integration” section of repositories settings.
Webhooks send an HTTP Post to a URL that you specify and are triggered by events in the repository. After a webhook is triggered, Beanstalk will send a JSON payload to the URL with information about the event. Since this payload is in a JSON format, it can be parsed by the receiving server. This allows you to send data about the event and create services based on that data.
An example event would be each time a push is done to a Git repository. In that situation, some of the information Beanstalk would pass on is what branch the push was to, who made the push, and what files were changed.
To take things further with modular webhooks, you can run pre/post deployment webhooks. For example, you could configure post-deployment webhooks with Jenkins. After a successful deployment, Beanstalk would trigger a Jenkins job to run tests against the environment.
Here are all the events that can trigger a modular webhook:
On each push (Git).
On each commit (SVN).
Every time a deployment is finished.
Any comment is posted on a changeset, a file or a code review.
When a branch is created.
When a branch is deleted.
When a tag is created.
When a tag is deleted.
When a Code Review is requested for a branch.
When a Code Review is approved.
When a Code Review is canceled.
When a canceled or approved Code Review is reopened.
When a new Issue is added to a Code Review.
When a Code Review Issue is marked as resolved.
API
For all plans, Beanstalk offers an API. If you want to build tools or services integrating Beanstalk, the API is for you. With the API you can do nearly action as you would in the web interface.
Do you need to generate new deployment environments on the fly? Programmatically create a new repository? Assign permissions to the repository you just created? These are all done with ease if you know how to work with a well-documented API. Or, you can get creative and do things like share common Sass files between repositories.
There are some great third-party apps available. Magic Bean allows you to manage your deployments on iOS or Mac. Habichuelas and Beansprout are mobile Beanstalk clients for iOS and Android.
Zapier supports Beanstalk, allowing you to connect to thousands of web apps with Beanstalk. For example, when creating a new Beanstalk repository you could add a new card to a Trello list to assign tasks around the repository.
Extend Your Productivity
The tools and services you can extend Beanstalk with are limitless. From updating a status in your issue tracker or notifying your entire team of a recent deployment. We hope connecting Beanstalk with the other services your business depends on makes life a little easier.
Is your favorite service missing an integration with Beanstalk? Leave a comment letting us know what you’d like to see!
Any developer can commit code — but knowing when to commit is often up for debate.
Most developers will admit that making a commit for every changed character, or keystroke is not best practice. After all, having too many commits can cause confusion, and clutter your commit history.
On the other hand, committing large chunks of code could lead to unfocused and incoherent commits. Somewhere in there is a happy medium, but how do you find that?
At Wildbit, we promote best practices by encouraging developers to commit early, and often. This article will focus on the benefits of doing just that. To begin, let’s focus on two attributes to keep in mind when making commits.
Commit Messages
We often talk about the importance of writing meaningful commit messages. These messages define the commit itself, and should be about one specific set of changes. And those set of changes should support that message.
In this light, addressing two separate bug fixes in a single commit, even if they are related would not be wise. Why? Good commit messages are often overlooked until you need to go back and find a specific change. But how do you locate that change if you habitually combine multiple changes into a single commit? It’s not impossible, but it’s not preferable, either.
With that said, here’s a question to ask yourself if you’re wondering what code to include in your commit.
“When I write my commit message, will it be about a single subject? Or will I be forcing other random and unrelated details from a separate issue?”
If you foresee yourself having difficulties constructing a clear, and defined message, it may be better to create two or three separate commits to flesh out your work.
What’s another way to test the quality of your commits?
Rolling Back
Let’s consider another scenario. Think in terms of rolling back to a previous commit. If you want to know if you’ve included too many changes in your commit, ask yourself:
“If I rollback to the previous revision, how much work would I lose?”
Let’s go back to our example earlier, but this time we’ll view this with a different lens.
You’ve fixed two separate, but related issues. You add these changes to a single commit, but then you realized you introduced bad code when fixing one of the bugs. Now you need to rollback to a previous state. But how do you do that without removing the useful code you prefer to keep?
This is where things can become tricky, and in most cases you find yourself wishing you had segregated each bug fix into their own commits. When you have the habit of committing early, and often it’s easier to see the journey of your feature.
Don’t take my word for it. Let’s test this out. Here are two git log code snippets of the same repository. Which snippet tells you more about the feature that’s being added?
Example 1
commit b0e77532b5a8cf236d95f1b3324aabc194568c60
Author: Ashley
Date: Tue Feb 29 23:12:05 2011 -0600
added contact us box to homepage and about us page
Example 2
commit b0e77532b5a8cf236d95f1b3324aabc194568c60
Author: Ashley
Date: Tue Feb 29 23:32:03 2011 -0600
added text fields on home page
commit b0e77532b5a8cf236d95f1b3324aabc194568c92
Author: Ashley
Date: Wed Feb 30 00:52:09 2011 -0600
added text fields on about us page
commit b0e77532b5a8cf236d95ashdad44aabc194568c12
Author: Ashley
Date: Wed Feb 30 01:15:32 2011 -0600
added buttons, and edit and delete options
The first code snippet describes the commit effectively. But that’s all it does. All the code has been consolidated into one single commit. If you’re looking for a specific piece of code, you’d have to sift through a lot of changes to find it. That’s not the ideal experience if you run into issues down the road.
The second code snippet shows the journey of this feature and how it has evolved over time. Now, you can revert to specific points of your development, without the fear of losing all of your changes. With this approach, it’s easier to show your colleagues all the changes that led to the end result.
Imagine walking up a flight of stairs that has missing steps. You may be able to get to the top, but if the gaps are too large, then it can be difficult.
Likewise, making small atomic, and self sustaining commits help you to think through the implementation process and write better code. If there are too many gaps in your commit history, it can generate a lot of confusion making it difficult to journey through your project.
Benefits
To summarize, what are the benefits of committing early, and often?
It’s easier to share your code. If you’re on a distributed team, its best to share your code as much as possible. Your teammates can integrate changes, and avoid merge conflicts worry free.
Context. When you commit early, and often you give your team and yourself a great deal of context. How so? It’s easier to track where a change was introduced because you have a detailed commit history. Introducing too many changes in a single commit, it makes it harder to locate problems when they come up.
Scope. Committing early and often will help you to see the journey of your project, making it easier to rollback to a specific revision if needed
Better commit messages. Better code. By committing often your messages will be focused, and meaningful because it relates to a specific set of changes, and not a series of unrelated modifications.
Summary
Remember, the purpose of the change is more important than the size of the change. Some developers feel that if you’ve only changed 1 or 2 lines of code, then you’re cheating yourself by committing a small amount of work. But that’s not entirely true. A small change like fixing a typo is worthy of having its own commit.
Don’t feel rushed to commit code because you’re wrapping up your work day. Remember, git stash is your friend that stores your changes until you’re ready to commit them. Save yourself time and improve the quality of your code by committing early, and often.
In order to have a reliable development process, you must take deployments into consideration. And while using services like Beanstalk or DeployBot are a step ahead of transferring files via FTP, you need more than just tools. If you put a solid, consistent process in place, your entire team and your customers will benefit.
The primary goal of a reliable development process could be summed up as, “No surprises!” And deployments play a critical part in achieving that goal. As Zach Holman puts it:
Your deploys should be as boring, straightforward, and stress-free as possible.
Let’s look at how a regular, consistent deployment process can help your team.
It takes more than bran flakes to promote regularity
The phrase regular process indicates regularity. That means it’s a task your team conducts on a regular basis. This results in familiarity and the lack of surprises alluded to above. If you’re only deploying a huge change to your production environment once every 6 months, guess what? Your deployments will be stress-filled, not stress-free.
There’s a reason why continuous deployment is a goal for many teams. It achieves this regularity and gets your team to deploying more frequent changes of smaller impact. Beanstalk enables this type of process with automated deployments.
For your development, testing, or staging environments, Beanstalk can deploy your changes automatically on each commit or push.
Achieve clarity
As well, the phrase regular process indicates structure. Your team is familiar with this activity in a certain manner. Better yet, if you document your process, there is an artifact to refer to for new team members or those still getting used to how your team does things. This makes it far easier for everyone to be aware of a few important facts:
what was changed
where was it changed
who changed it
The team knows where to get this information because of the structure of your process. And Beanstalk provides plenty of options for how to find these details, ensuring the success of your process.
It’s easy to go back in time
Another advantage of a consistent deployment process is it enables you to think of your site or app in linear terms. You can picture your changes reaching back in time with each deployment highlighting a specific point your project/product’s timeline.
The beauty of this is the ability to go backwards. If things go south, if you introduce some bad code (and you will), rolling back to a point in your timeline is a simple step. Most of us have experienced that sinking feeling moments after overwriting the previous state of a production web server with no means of going back.
Having your code in version control gives you something to go back to in these scenarios. But that’s still a lot of work (rolling back your repo, finding the required files, or deploying from scratch once again). But when you use deployment services that focus on this stuff, rolling back is as simple as deploying the last clean version of your code. If you deploy frequently, rolling back involves a manageable, smaller group of affected files.
Again, Beanstalk enables this ability. Prepare a manual deployment and choose the desired commit to deploy again. Beanstalk will ensure your end destination is modified to resemble the state of your repo at the desired commit. Within seconds, you’re site or app is back to the previously working state.
Time better spent
Last, this consistent deployment process allows your team to make the most of their time. There does not need to be any lengthy investigation with team members asking, “What happened?” Investigation of a specific deployment takes seconds with a deployment service. Those questions above (who, what, where) are answered in a matter of seconds.
Instead, teammates can focus on building that new feature with zero bugs. Or cutting page load times in half. Or deciding which new prototyping tool is best . Or whatev. When the toolset and the process are well known, it leads to a more relaxed environment where team members can focus on the things that matter most to them.
I recently had a conversation with a non-technical customer who ran his own business. He came to us with the statement, “I’m tired of my developers overwriting each other’s work!” We understand that pain — it’s why we build products that we hope make people’s jobs a little bit easier.
But again, it takes more than just good tools. Every developer — and development team — needs to take the time to reflect on and formalize the process. Nothing too crazy … just enough to get the job done each and every time!
We’re excited to share that our friends at Zennaware have announced that the latest version of Cornerstone is now available. Cornerstone has long been our favourite client for Mac users who work with Subversion.
The latest version sports a completely redesigned interface, with major improvements to the source list and the inspector. As well, the new design fits more nicely with its environment, using Apple’s HIG (Human Interface Guidelines). It has also been updated to use macOS’s built in notifications. Performance and usability were also a focus and Cornerstone users should enjoy the changes!
Don’t forget: Beanstalk customers can get a discount on a Cornerstone license. Just use the code found on the Getting started link for any SVN repo in your account. If you have any questions, let us know.
Beanstalk allows designers and developers to store source code, track changes, and collaborate with team.
