On Becoming A Productive Developer
Peak performance for engineers
This piece was originally written by Dani for the Pixability Tech Blog in March 2016, and was the best performing engineering blog post (which has since been moved to Medium). Dani also presented it as a talk at Women Who Code.
Even if you don’t grow up watching sci-fi or major in computer science, it is still possible to grow up and write production code. I joined the Pixability team with a non-traditional software engineering background after graduating with a degree in Biological Systems Engineering and attending a 10-week software development bootcamp. I continue to spend hours teaching myself, learning from mentors, and trying to cultivate good habits.
Most of my good habits stem from my rowing days, when I began experimenting with optimizing performance. “consistency and improvement,” one of my guiding principles, was instilled in me by my collegiate coach. Workouts were recorded in spreadsheets every day. Performances were ranked by time, and then color-coded based on the individual’s previous best performance. We typically finished the first practice by 8 a.m., so the spreadsheet set the tone for the rest of the day. We learned that performing consistently and improving incrementally eventually leads to success, especially when conditions are less than ideal. This philosophy has become invaluable in trying to master a new craft, software development.
I continually iterate on my own personal process, and recently started to document ways to become a productive developer: onboarding, productivity, development process, and goals/habits.
Onboarding
Wouldn’t it be really convenient if every company had an existing style guide? Even a good style guide will evolve as the company grows. New hires can bring a valuable perspective to the onboarding process and style guide.
When I join a new team, I also find it helpful to:
Learn about the team’s best practices, tools, process, and style guide.
Ask questions early and often.
Discover what blogs or other resources the team subscribes to.
Identify potential mentors.
Get access to tools and set up the work environment. Get familiar with the team’s architecture, documentation, apis, and code. I currently use:
Communication: Slack, Gmail, Google Hangouts, in-person chats, meetings
Task management: Momentum Chrome extension, Sunrise calendar, Jira
Documentation: Confluence, Gliffy, Google Drive
Development: Sublime, iTerm, Postman, the Pixability app, Chrome developer console, Batarang, GitHub, Sourcetree
Architecture: Angular 1.5, Angular Material, gulp, jspm, npm, lodash, es6, traceur, js-data, ui-router, less, karma, jasmine, selenium
External partners: Facebook business manager, Facebook marketing api
Personal: Spotify, SoundCloud, Google Play music (previously Songza), podcasts, Evernote, Sleep Cycle
Productivity
During a typical work day, developers must balance features, bugs, meetings, Slack/email questions. interruptions are a real concern. In order to maintain optimal focus, we also need to manage hydration, nutrition, mobility, and mental clarity. One way to do this is to make lists and follow routines. I am constantly tweaking the routines to enhance my performance. It takes time to identify what works and eliminate what does not. The more I can automate, the more I can experiment with new ideas.
A brief summary of my current routines:
Morning: coffee, water, contrast shower, read, write, meditate, exercise, work on mobility. The morning routine primes my mind and body for the rest of the day.
Beginning of the work day: update the stand-up sheet, stand-up meeting, start work on MITs. Like Mark Twain said, “If it’s your job to eat a frog, it’s best to do it first thing in the morning. and if it’s your job to eat two frogs, it’s best to eat the biggest one first.” If I can do the hardest tasks first, the rest of the day is relatively easy.
Mid-day: take breaks, go for walks, drink more water, grab lunch with team members. Giving my mind a break helps my afternoon productivity levels. Team bonding improves overall product quality and team output.
End of the work day: set MITs for the next work day, save state for any incomplete tasks, update the stand-up sheet. These little tasks help me start the next day seamlessly.
Evening: pack for the next day, and most importantly, practice good sleep hygiene. I believe every successful day starts with the previous night’s preparation.
I keep my personal to do list on Trello. I organize my lists similar to our Jira dashboards: triage, backlog, to do, in progress, review, completed.
Minimalism has had a profound effect on my ability to focus on what really matters.
Development process
Every great team excels at communicating. In software development, this can take many forms: meetings, tickets, documentation, code reviews, product requirements, interaction design, readable code, descriptive git messages, and sprint planning, among other things.
Regular communication across product and engineering teams is essential to quality and efficiency. According to Jonathan Snook, “…we use the terms front-end development and backend development but people are often confused as to where a front-end developer starts and where a backend developer ends. When we examine the development process, there are three phases: ‘design’, ‘design implementation’, and ‘application development’:”
Cross-team communication should also include status updates on features, bugs, risks, blockers, release schedules, regression testing, and process. Our front-end team lead, David Colwell, has developed a bulletproof process:
Investigate
Design & planning
Foundational prep
Develop
Test & tweak
Cleanup
Review
Tips for being a decent human and team member:
Write small functions. Channel my inner Venkat. For each function, I ask:
“Can I easily write unit tests for this?”
“Could someone easily debug this?”
“Would I want to revisit this code in six months?”
“Do I need to write comments? Can I write the code in a way that is readable without comments?”
Before pushing code:
Ask, “Is this code acceptable to add to the codebase?”
Ask, “Am I adding technical debt to the project?”
Think about other sections of the codebase my code might affect.
Ask for feedback.
Run tests.
Commit the smallest diffs possible and only change what is necessary. This makes it easier to d o code reviews and find commits later that caused trouble.
After pushing code, ask for a code review, welcome feedback, and document work. Documentation not only helps QA and the other developers, but I also find myself referencing my own documentation regularly:
Tables, mind maps, and other visual examples
Links to internal and external apis
Screenshots and screencasts
Whiteboard sessions
Complexities and tech debt
Related tickets
Even using the development process discussed above, I still find myself getting stuck occasionally. When this happens, I first attempt to solve it independently by:
Asking myself, “What if it was easy?”
Writing down:
What I know
What I don’t know
Assumptions
Constraints
Research that needs to be done
Complexity (i.e., mind maps)
Possible risk
Using Google and Stackoverflow (i.e., don’t try to reinvent the wheel).
Focusing on the smallest possible piece at a time. Break the problem down. Try to get a simple example to work and incrementally build on that success.
Identifying the best questions to ask.
This independent problem-solving system prepares me to ask effective questions. There are various approaches to enlisting help:
Ask the question directly. This is the easiest option when the answer is simple.
Brainstorm with other developers and designers. Sometimes an entirely different design or technical approach is needed to solve hard problems.
Pair program, especially when touching unfamiliar code or logic. This has several benefits:
Teaches developers to write better code and develop better habits.
Manages complexity.
Increases efficiency in code reviews.
Reduces number of potential bugs.
Shares knowledge and ideas across the team.
Goals and habits
Developing good habits, set goals, and get feedback ensure consistency and improvement. Some of these recurring practices include:
Looking things up that I don’t understand immediately. If time is limited, I add it to my learning list.
Welcoming and requesting feedback, beyond just code quality.
Sharing knowledge and resources.
Assuming that I could always improve. Consistency and improvement.
Being confident that every problem has a good solution.
Iterating on process, especially as the team grows.
Making it fun!
Staying curious and constantly learning…
Conclusion
As always, I am looking for new ideas to improve. My current favorite resource is podcasts. Tim Ferriss deconstructs world-class performers on his podcasts and I borrow ideas from other siloed professions. What do you know that could help us? Share your suggestions!
Inspiration/resources: