Embrace fragmentation.
This is the mantra behind microproductivity, an efficiency strategy spearheaded by researcher Jaime Teevan.
“The transformation of work into microwork will change when and how people work — enabling individuals and automated processes to efficiently and easily complete complex tasks,” Teevan said while speaking at a University of Washington seminar.
This method of breaking up a large project into bite-sized pieces is a tried and tested framework for David Musachia, a senior security engineer at Vibes. Dividing complex work into simpler tasks allows Musachia to map the progress of his work more efficiently.
Software development can be messy, lengthy and stress-inducing. To stay consistently productive and inspired, engineers need to find the right tips and techniques that fit their working style. Built In Chicago caught up with three engineering experts to hear what they do to stay successful in the long term.
Vibes is a marketing technology company that provides an intelligent mobile messaging platform.
Tell us about one of the principles, habits or rituals that differentiates your unique approach to engineering. What made you start doing this?
When you are assigned a task or given a problem to solve, the ambiguity and numerous paths to achieve the end goal can be endless. To help me zone in and be efficient with my time, I reference guidance that was provided by my mentor: achieve small, continuous improvements every day.
With this mindset, tasks and milestones can be structured and broken down into more digestible pieces that make working easier and more productive. In addition, this allows me to show progress throughout the process, keep key stakeholders in the know and provide suggestions and feedback as the work is being completed.
What differences did you notice after you adopted this new principle in your work?
Putting this principle into practice enabled me to deliver solutions faster. After a minimal viable product is implemented, I can iterate and improve the solution over time. This allows the stakeholder to be content with an implemented solution and me to make enhancements in the background.
Previously, I was always striving to provide perfection in my initial solution, leading to a slow turnaround. You need to build up to your desired state. An example that comes to mind is when I was assigned to create a lambda function to use a container to generate alerts in the centralized ticketing system. There are many different components to this process. I attempted to deliver the final product from the get-go, and it proved to be rather difficult as I ran into numerous errors throughout the process.
“You need to build up to your desired state.”
I switched to using the “small, continuous improvements” method. I broke down the solution into digestible pieces by first focusing on writing a containerized script, deploying the resources by hand and using infrastructure as code to deploy the resources. The new approach allowed me to share progress with the stakeholders and enable feedback to be incorporated into the solution.
What does this approach to engineering help you and your team accomplish?
The “small, continuous improvements” approach to engineering has helped me manage my time. I am now able to handle a multitude of assignments and show progress being made on each one. Ultimately, this has made me more efficient and productive, allowing me to accomplish tasks faster. Overall, this helps the team to identify additional initiatives to focus on and complete. As the team is enabled to accomplish more, we as a company are in a better position because the turnaround cycle is shortened.
Caxy is a custom software development and consulting agency that drives business and technology strategy for other businesses.
Tell us about one of the principles, habits or rituals that differentiates your unique approach to engineering. What made you start doing this?
Staying organized is key. I try to schedule architecting and thinking near the end of my day, whenever I inevitably hit that wall. It doesn’t work for me to problem-solve while I’m in front of my computer and getting frustrated why it’s not working. I go to the gym and think it through. It’s like a good mental refresher and also helps me think clearly. This method is not always feasible because sometimes you don’t get to control when all of your architecture meetings are, but it’s something I like to try to do — especially if there is an issue that’s been lingering around the team. I usually try to make sure to revisit it before the end of the day and then I can hopefully bring it in the morning.
What differences did you notice after you adopted this new principle in your work?
I feel like you can’t be a leader if you’re not organized because you are responsible for organizing and running a team. If you couldn’t stay organized, you wouldn’t be in the position you’re in. It is definitely a critical piece.
The other major difference that maybe isn’t talked about is communication skills. There are engineers out there who maybe don’t have particularly good communication skills. But in terms of being good at your job, communication is really important. How do you disseminate complicated architecture in a way that is digestible quickly without having the world’s longest essay in Slack? How can you talk to a client who is not tech-savvy? How do you explain it in a way that gets the point across while not also drowning them at the same time? This also includes communication with the team and the product manager and everyone else. How do you disseminate information? Communication is super, super critical.
“The other major difference that maybe isn’t talked about is communication skills. In terms of being good at your job, communication is really important.”
What does this approach to engineering help you and your team accomplish?
This approach allows us to keep an eye on the forest and not get lost in the trees. It’s easy to get sucked into a particular feature and not understand how it fits into the bigger picture of the product as a whole. Keeping yourself organized will save you from creating something that doesn’t make sense six months later when all the pieces need to come together.
IMC Trading is an international proprietary trading firm active in over 100 trading venues.
Tell us about one of the principles, habits or rituals that differentiates your unique approach to engineering. What made you start doing this?
Solving complex problems in code often involves repeatedly side-tracking yourself, whether it be to investigate how a piece of code works or why it doesn’t, working through challenges via trial and error or making frequent jumps to work on different parts of a solution. My brain has no concept of short-term memory. If I put down a problem halfway through finishing, I will have completely forgotten where I left off and how I got there.. This demands additional time and effort to catch up with myself, but more importantly, it can lead to specific implementation details or considerations being lost.
To make up for this shortcoming, I document all of my thoughts and concerns in somewhat lengthy, bulleted-list comments that are left next to the relevant piece of code. It’s not uncommon for a programmer to write out pseudocode, but my comments often more closely resemble an argumentative essay than a note.
These comments never make it into the final product, and many would consider writing such detailed notes excessive and time-consuming. However, writing things out allows me to put important details into longer-term memory and provides good documentation for when I inevitably get side-tracked and come back several hours later. When I’ve successfully worked through one of the documented challenges, I remove the corresponding parts of my comment until the entire problem is solved and my notes are a clean slate.
“Writing things out provides good documentation for when I inevitably get side-tracked and come back several hours later.”
What differences did you notice after you adopted this new process in your work?
I may know from the instant I start working on a project that a particular issue is likely to arise, but unless it is written down in an obvious location, it is easy to forget it when I am in my zone writing code. With this approach, I have almost completely eliminated the possibility of delivering a solution that forgets to address a challenge I noted hours or even days ago.
Additionally, I greatly reduce the time spent double-checking that my work solves the problem before submitting the code for review. Without good documentation of all the scary scenarios that might break my code and what I’ve done to ensure that doesn’t happen, I am constantly reiterating those scenarios in my head to be absolutely certain everything will work as expected. With this approach, however, I only have to revisit each scenario once, and I’m confident I haven’t forgotten anything important.
What does this approach to engineering help you and your team accomplish?
This approach is critical for my team and me to work together efficiently. Spending extra time doubting my work or checking things over and over again most obviously slows me down, but it can also slow my team down if I am not able to review other members’ code, release work that other members need for their own projects or require too much of their time reviewing my code.
