A great internship or first job blends responsibility, real-world experience, and great mentorship. As we strived to create that balance this summer, our engineering team formed a book club for interns and recent graduates to talk about their experiences, read a different perspective, and learn from each other. In this blog post, you’ll hear from three of our interns on how the book and the discussions that followed changed their engineering habits.
One of the best learning experiences of our internship at Civis Analytics was the intern class’ close reading of Edmond Lau’s book The Effective Engineer. This four-week book club gave us the chance to learn from the experience of Edmond Lau, and incorporate the lessons he learned about being a high impact engineer. The process of discussing the book with the other interns also gave a deeper understanding of the material and how it might apply to the internship. The book really shaped our mindsets towards developing software.
During my internship, I was responsible for working on a few different tasks at once. While I wanted to do a lot of different things, I still wanted quality. The question of what to work on when was persistent. Lau suggests a few ideas for this, and I’ll share how these worked out for me in practice.
Lau suggests you create a task list, a reasoned, ordered stream of activity. The best thing to do, he says, is to regularly update this stream based on the leverage of each action, or the value added divided by time spent. This can, at times, mean addressing things that aren’t urgent, but important.
I used Google Keep at the beginning of everyday for 15-20 minutes. For each task, I would spend a few minutes amount of time detailing the idea before moving on to the next. This included verbose descriptions of current bugs in a branch, tagging someone for code review, and listing new concepts to explore for potential solutions. This last one is important.
This strategy paid off as, little by little, I learned more about features in say, Angular, that I would go on to use in branches later that day and later that month. Ultimately, it gave me more context for the tools in our stack. This habit personally conflicted with my sense of doing the most urgent task first, but adding in these more long-term goals helped pace the day better for myself and made me a more cohesive engineer.
Lau spends a lot of time talking about optimizing your workflow, which leads to faster iteration and more productivity. This involves taking a step back and seeing which phases of your development process slow you down. This is important as slow steps will take up much more time than necessary, interrupting your flow of thoughts. I have, in particular, worked hard on one point on optimizing workflow: mastering the programming environment.
Some examples he uses are mastering your text editor/IDE, getting familiar with shell commands, and making sure your debug flow is faster. I spent quite a bit of time mastering my text editor, vim. (Side note: while this post is vim-specific, many of the tips could be helpful for any command line text editor, including Emacs)
A quick step to getting a nicer vim environment is just editing your ~/.vimrc. There are many examples online and it greatly improves the experience from a curt, black-and-white text editor to a more descriptive, colorful editor.
The bigger step, for those that want to dive deeper into the world of vim, is to fill in a lot of functionality gaps that are important in a modern text editor. I previously used Sublime Text for projects that I deemed too large for vim. I tried to make Sublime more vim-like with Vintage mode, but, frankly, it’s awful. So, what was I missing in vim that Sublime gave? Various things: including fuzzy search, file search, a file tree, and fast shortcuts, among others little things. Combined, these things make vim a pain to work with on projects with a significant amount of navigation required. The problem with vim is that it does not come pre-installed with any of this functionality. Rather, you need to go out and find these plugins. So, first things first, a plugin manager. Some popular options are Vundle and Pathogen (this takes a bit more effort). Next, find the plugins that fill in the functionality gaps that you have. The great thing about Civis is that everyone is eager to help each other, which is why I got most of the plugins that I currently use from another developer there. Some quick and easy must-haves include vim-sensible, ack.vim (or its more performant counterpart, ag.vim), and ctrlp.vim. For those that are welling to spend some more time, I also highly recommend YouCompleteMe. To actually install these plugins for Vundle, you just put Plugin ‘github-user/github-repo,’ or another naming format that it supports, in your .vimrc and you’re ready to go.
I find that I work faster with vim commands. Iterating quickly not only allows you to contribute more to the company, it also allows software engineers to learn more quickly.
The Effective Engineer helped me take a longer-term view of the software development process and helped me justify long-term investments in my coding productivity. The book emphasized the importance of tooling and the long-term ROI that is possible when a coder invests time in improving their development process. Lau places an emphasis on reducing iteration speed, the time it takes to run an experiment, see the results, and get back to experimenting. Because of Lau’s book, I started investing much more in tools like Sublime Packages, superior testing frameworks, and keyboard shortcuts that make me a more efficient developer and reduce my iteration speed.
The book also caused me to question many aspects of the software development process that I previously viewed as unassailable truth, and weigh their pros and cons more objectively. Lau questions practices like coding reviews, automated testing, and paying down technical debt, pointing out that each of these practices trades off quality and iteration speed. He points out that sometimes iteration speed matters more. This has changed my approach to testing in my personal projects. Instead of viewing each test as equally valuable, I now work first on the tests for the most critical and most used parts of the codebase and add other tests later when the utility of the software is validated.
Do you have any tips on how to become a more effective engineer? Share them with us on Twitter @civisanalytics.