4 Lessons in 4 Years at SmartLogic

Tomorrow is my 4 year anniversary at SmartLogic. It got me thinking about some of the learning I've experienced over the last few years.

Most of these points are largely nontechnical. I could dive deep into learning Elixir when I first arrived or React around the same time. I could talk about the various PD tangents I've gone on over the years (Machine Learning? Crypto? DevOps). But those would obfuscate the central learnings which are:

1. Don’t be nervous.

I tell all the new people this in not so many words. you’ll be nervous the first six months or year or so. This is natural. You’re just getting the ropes.

My encouragement is: if the nervousness/anxiety is unpleasant to you, let it go! Your teammates love you and they’re gonna help you to succeed.

When I first came to SmartLogic I shadowed a guy who told me "We use vim here". I took that to heart and spent my first few months at SmartLogic struggling to develop in Tmux and Vim. Now I have a hard time imagining developing without those tools.

Giancarlo was looking out for me. Sure I probably just did what he said because I was nervous I'd be judged for using the free version of Sublime Text. That doesn't matter now. What matters now is that I'm sure glad I spent the last 4 years in the terminal because it forced me out of my comfort zone where I could become more familiar with all the tools *nix has to offer.

I know that's easier said than done so here are my quick tips:

• Take 10 deep breaths while doing nothing else.
• Take a nap.
• Try to identify the source of your anxiety and reframe it in a way that works to your good and the anxiety becomes excitement, or enthusiasm.

2. Always Get Better

Professional Development is not limited to one afternoon once a month and it's not limited to technical skills.

Every single meeting is an opportunity to improve your listening skills, your speaking skills, and your thinking skills.

I had to learn what not to say as much as what to say. Economy of words is a virtue (that I continually aspire to).

Every little inconvenience you find while programming is an opportunity to solve a problem and learn your stack just a little bit better.

Learning tmux and vim is a great example of this. The more I slow down (see point 4) and improve my tmux and vim scripting skills, the more long term gains I get from using those tools.

Oh it sucks to run like 4 different servers in 4 different terminal panes to run the app you’re working on? Write a setup script using the tmux commands you learned from the smart devops people on staff.

3. Double down on what works.

If you’re effective contributing somewhere, own that as much as possible! Own features first and own projects later. If you're here four years you'll be humbled by your own work early on and you'll be proud of the cumulative work you've done.

Most recently this has been super clear from our work in the community,  on the podcast and in some of our older apps, including one I’ve now worked on for four years.

Communication works. Double the amount you communicate.

One of the best things I've been trying to do this year is an afternoon follow-up message on my standup (I don't always do it but am trying to do it where applicable).

One true thing about client work is this: the client likes to feel like they really know what's going on and that their needs are understood. One way to do this is constantly communicate and reiterate key aspects of the system or process. This has been super important on the largest projects I’m currently working on.

• Heads down focus works. Double down on deep work and try to cut context switching and distractions in half.
• Meetings are necessary and should be batched.
• Block time doesn't mean uncommunicative time.
• Turning off Slack for a couple hours is OK.

4. Slow Down

This is the biggest lesson I've learned in my fourth year here. I need to slow down. I need to review my own code and smoke test my own features. I need to diligently practice TDD like I was taught almost 10 years ago when I first picked up Ruby on Rails.

Taking your time is the right thing to do. It's what separates the pros from the hackers.

And it's not just a technical thing. I need to think about what I say before I say it. I need to consider my questions carefully so I know they are clear and supplying adequate context.

Plan your day at night and in the morning. It doesn't take much time but the days I do go much better than the days I don't.

The more we think about our questions and flesh them out, the less back and forth will be required to solve the problem and the less context switching will be imposed on our teammates.

Triple read every email you send.

Speak slower and you'll be better heard.

Header photo by Kristopher Roller on Unsplash