Eleven software lessons in 2015
In 2014, I really learned some great lessons as I transitioned from freelance consulting to full time work. So primarily these are lessons I learned while working at a job in the first 80% of 2015 and then transitioned to another job in the last part of 2015.
Lesson 1 – Pair Programming Can Be Invaluable
I’ll qualify this by saying I only did a little bit of “pair” programming when I transitioned from my job at a university to a startup job. There was no pairing culture per se, but a coworker and I would sometimes help each other debug or figure out the code that needed to be written for a new feature.
I got to catch a glimpse of my pair’s workflow and how they approached problems. I found sometimes talking a problem through could help me think of a new way to approach a problem I was stuck on and vice versa.
Lesson 2 – Layoffs suck
I’ve heard about layoffs, but I had been fortunate to not really experience them until 2014. Layoffs naturally makes people nervous about their jobs.
The other thing it signals is that the company typically has a revenue problem. It can be a strong signal for the other workers who don’t get laid off to start looking. It’s why there’s a lot of advice out there that tells managers that if they have to layoff, they should only do it once, explain why, and then do their best to turn their situation around.
If they don’t, what will happen is that the workers with the most job options will gradually start leaving until there’s nobody left to help run the company and turn it around.
For the people that are left, it usually means picking up the work your coworkers left behind and in general it’s just a more stressful and fearful environment.
Lesson 3 – Document what you’ve done at work on an ongoing basis to help you keep your portfolio updated
One thing that’s helped me is to set aside time in my calendar to document what I’ve done at work to help keep my resume and portfolio updated. Not only does it help me reflect on what I’ve done, it acts as a bit of a prompt to help me think about where to go next.
The other thing it does is help you during a job search. Now you’re more prepared to talk about you’ve done to a prospective employer. Plus, when you change jobs, you’ll be really busy wrapping things up at your current gig and you’ll be hard pressed to find time to document your work.
Lesson 4 – There’s no such thing as a perfect job, but you can find one with tradeoffs perfect for you
There’s only tradeoffs in life. Sometimes it means you take less money to find a job or environment you’re more ideally suited to (although I will say with the job market as it is for programmers, you shouldn’t have to do that, you can read this article on job offers to ensure that you don’t).
As an example, when I transitioned away from one of my first web development jobs to another company I found that while I was earning more money, I also had less time for myself, since the company was a startup where long hours seemed to be an expected norm.
Lesson 5 – Culture matters
Working at one of my first Ruby on Rails jobs, my manager there was an early-riser and from initial impressions, I remember they thought starting later than 9 am was a bit too late. But at another job at a startup, my manager would often come in as late as 10:30 am. You could also work remotely.
So the startup definitely allowed for more autonomy and trust, but there was also a lot more chaos. With the previous job, the environment and expectations were more predictable.
Lesson 6 – Nice coworkers make a difference
I think I’ve been fortunate in that on balance, I’ve always had nice coworkers. I’m sure I could dredge up a horror story here or there, but even during stressful times (like layoffs), having reasonable and nice coworkers made a difference.
Lesson 7 – Putting non-programmers in charge makes the culture more “business-driven”
Throughout my working life, I’ve had managers who had the technical experience and managers who haven’t. If you’re a programmer (or other technical person), having a non-technical manager means you can improve your skill at communicating why a software deadline may not be met or the technical constraints around why something can’t be done.
Having a non-programmer put in charge of a programming team (or set of programmers) can potentially create political headaches as well. Why? Since they have no experience in the field, they come to rely on whomever communicates with them reliably in a manner they understand (sometimes that translates to whomever they like the most).
Depending on how political your team is, this can result in frustration for all the programmers involved and possibly higher turnover.
Lesson 8 – Command line mastery is important
Having come to Ruby on Rails through tutorials and self-teaching, I have to admit I didn’t have as solid a grasp of the command line as I would have liked. But what I’ve found is that mastery of Unix command line tools (like cURL and Vim for example) greatly aids your ability to turn out working programs.
It helps with debugging (e.g., using cURL to test an http request and debug an http request/response workflow) and I think the best programmers (at least as I’ve seen them) seem to have it.
Lesson 9 – Be aware of your environment (and politics)
I’ve basically had one job in my life that was pretty much free of office politics. Basically, I was on a team of people who were retired or about to retire. Those were some good times :). And it kind of spoiled me in the sense that when I got to other jobs I was shocked by all the office politics.
In fact in one particular job, I decided to read up on how to deal with office politics written by a former HR executive. Suddenly, everything made sense. It was also quite sad on how much sense it made. I won’t bore you with the details as I think this book covers it nicely, especially if you feel like you’re dealing with big company style politics.
The upshot is all the politics can affect the types of projects you are assigned (and hence your growth in skills), so it’s wise to pay attention as you try and grow your career.
Lesson 10 – Really try to focus what you want out of a job
This is one thing I could have done (and still am trying to do) better. During one interview for a senior role, the hiring manager really liked my personality and felt I could do the job if I had more specialized experience.
The job was a bit of a long shot, but it also made me realize that I needed to focus more on the types of experiences I was getting out of my programming jobs.
Lesson 11 – Changing jobs can be time-consuming so know what you want out of your next job
Understanding where you want to live (which I’ve already written about in this post) can help you produce better coding samples in my opinion.
It can also help you save time and money. I’ve written about what to think about beforehand in this post.