The following is my professional six month journey as a first time lead web developer, the purpose of this writing is to share my experiences and some of the toolchains I’ve helped implement. Think of this as a “swiss army knife” for future technical leads! Enjoy.
Follow Your Passion
“Choose a job you love, and you will never have to work a day in your life.” – Confucius
I was hired as a ‘lead web developer’ on April 25th, 2015 and my first day on the job was on April 30th, 2015. Prior to becoming a lead I spent close to three years as a front-end web developer at a digital marketing agency; overall, I spent close to five years in the digital advertising world!
Before accepting my current role I was also offered a ‘Senior Web Developer’ position at a renowned marketing agency, but due to my experiences I’ve shared in a two part post; I wanted a change.
I want to point out that a ‘lead’ or a ‘senior’ position are just titles. If you want to become either in the near future for the sake of the title then I must say you’re doing it for the wrong reasons. There is nothing wrong with career growth, but grow with the intentions of making contributions on the careers of others and at the company level as well.
I have been insanely lucky and grateful to have worked with my previous leads, Butch Flarida (Lead SEO) and Phuc Nguyen (Lead Developer), they both contributed to my professional growth.
I must also admit that I’ve been blessed by the opportunity that my current employer has given me to build the technical department from the ground up. The set-up is pretty simple ‘flat-management‘ to foster creativity.
During my time in the digital advertising environment I experienced a lot of project downtime due to the bureaucracy of “project managers” and non-technical managers; a very frustrating time.
Without further ado, I will share some practices and techniques I have helped implement.
These practices are meant to achieve the “ultimate” goal, which is, of course: Creating a strong technical environment that can be relied on and which empowers the developers to do their best every day, feeling secure and aware of the quality of their code and work.
Don’t Be the Jack of All Trades & Master of None
Do You Use the Best Tools Money Can Buy?
I am sure some of you have been employed at some point in an organization that don’t take software or web development seriously. If you’re using on a daily basis an unlicensed version of Sublime Text in a professional environment; I suggest you quit.
Poor tools will deliver poor products!
Top notch development teams don’t torture their developers. Even minor frustrations caused by using underpowered development set-ups add up, making developers grumpy and unhappy. And a grumpy developer is an unproductive developer. Enough said!
The technical process isn’t the only thing a lead has to maintain properly, the information flow is also essential for the success of any project. It’s true that a lead is not a “Scrum Master”, but you should help the Scrum Master to facilitate the information flow, possibly even help the project managers to define stories.
To improve code quality, help the team to size stories by highlighting possible technical issues. For these, and many other reasons, having a good understanding of the most used (agile) frameworks, like Scrum, Kanban and XP, is very important for a tech lead. Because, as leader, you should be able to lead by example, showing and encouraging your team to follow agile best practice and guiding them to success.
There are several practices to ensure the quality of the projects you maybe working on, but the most important one is; without any doubt, feedback loops.
As you know, working on a new project is more empiric than scientific, which is why we need data and small, but incremental improvements if we want to meet the needs of our users or clients. Feedback loops are a very basic but powerful methodology designed to help us and our teams to succeed. With feedback loops, you are sure you’ll get the feedback and data that will allow you to improve your projects.
Moreover, thanks to the feedback loops, you will also have some measurable data to show to managers or technical architects to justify the technical decisions you’ve taken, show how a project has progressed and what kind of issues your team encountered during the development process. Know how to cover your ass…!
Pair Programming & Code Reviews
Two practices that could provide you with immediate feedback and benefit are pair programming and code reviews sessions.
Let’s start with pair programming first:
When we first pitch this practice, the first thing we’ll have to justify to our managers is whether the effort of using two resources on the same piece of code is worth it or not. When you have experienced and know how pair programming works, you should be able to increase both team productivity and quality of the code. This can enable a reduction of ‘features’ (bugs) later in the development process.
In my experience with one-hour pair programming sessions they have help to reduce future unnecessary costs (hiring dedicated testers) when we find and squash bugs on the fly. Pair programming sessions should not exceed one hour, and should be used at least daily or three times per week depending on the size of your organization.
Let’s move onto code reviews now:
At my previous positions this practice was often skipped. Code reviews are an essential practice of the software development process. It helps teams read, understand code and test each others ‘technical chops’, it also, helps maintain the code consistency and improve the project on a technical level.
If you don’t have enough time to do code reviews, I suggest to commit your code in your version control system and ask one of your colleagues to check your code that same day. A lead should always keep open time slots during the day to check the code of other developers. Remember that code reviews can be a genuinely powerful and effective technique if used properly.
As a tech lead, you should be the guardian of the organizations code base. Having a messy code base means that, after a few months, or even a few years, the company or a team would no longer be able to maintain that project or would struggle to implement new features or understand how to solve bugs.
In this case, I suggest reminding your colleagues about, the “boy scout rule”:
“Always leave the campground cleaner than how you found it!”
The best solution I suggest to implement is git. The tools, resources and documentation available for git are superb, which is why I suggest having git as your version control system. Please make sure you begin with a clear branch strategy, you can avoid having a wild west project branch by implementing a git flow or Bitbucket flow strategy. You’ll find that implementing one of these two strategies will increase the productivity of your developers and avoid the constant conflict issues when you try to merge different branches.
A lead should also implement a clear tagging phase and proper comment writing when developers commit their code. In particular, when you work with software releases or with libraries, it is fundamental to tag every stable version of your code before distribution. Last, but not least, when the developers commit new code, ask them to describe accurately what they have changed and, if it’s possible, commit frequently during the day, so they can easily revert the code or resolve any conflicts in the code base.
This is a must have technique in your development process! As you know the up-front design of any project often leads to wrong assumptions, misinterpretations and having too much guessing on the technical side. The best way to approach a project on the architectural side is to have discussions at the beginning of any project to allow you and your team to start the proper development process.
By doing this, you’ll create an organic architecture that will perfectly cover the needs of your company project needs and will facilitate the implementation of new features or refactor. You’ll see that, at the beginning of the project, you’re going to invest more time in the architecture, but after a few iterations, you’ll see less investment and plenty of benefits for the consistency and quality of your architecture.
The best way to design an architecture is in front of a physical whiteboard, where you can have immediate feedback from other team members and you can also quickly add, modify or delete elements. Remember that this documentation, if not updated, will not be used inside the company, so what’s the point of using expensive modeling software when the code should explain the decision by itself?
My personal suggestion on this topic is to create a high level view diagram on how the main components of your system are related to each other, and how your architecture works or should be improved. In this case, the document is very easy to produce and doesn’t require too much effort to be updated.
Hello Jenkins CI and Travis CI: The automation should be defined at the beginning of any project, if it’s not already defined at company level. Having a reliable and deployable solution to use over and over during the development of a project is mandatory! Usually you should be able to automate:
All the integration, acceptance, regression and functional tests for your project, possibly hooking your version control solution with the automation tool you are using to run all the tests for every commit. By applying this, you’ll be able to adjust the quality of the code release after release, keeping a high code standard and retrieve metrics to plan a strategy for improvement inside your team or company.
These are really the key activities and techniques that any tech lead should master and encourage during his/her daily routine. You definitely need to be flexible and skilled enough to apply the right approach to any situation in accordance with the business requirements and in line with company strategies.