I have written these posts several times before. Usually I make a list of a few ‘it’ technologies, a few small and high profile community events and that’s that. Of course, for good reason, I never get to most of these ideas to develop a new skill. Most people are in similar situations, I think. We have things we want to do and no time to make any real progress. 2018 will be different for me. I am starting a new contract in January, and the business I am apart of is rapidly changing and growing. 2018 will be a year of forced skill development. These aren’t things I’d like to do when there is time….if there is time.
Here is the list
Earlier in 2017, I wrote about some of the dynamics of working from a home office. I have worked from my house for about 50% of my career in technology now and have settled into a routine. Working from home isn’t a novelty for me, it is how I prefer to work and helps me to design a life that I want to live. Offices are wonderful for some people, they provide a format and structure for every day, as well as some forced social interaction.
Getting to the point where working from home requires time so you can acclimate, and also building something that resembles a usable office space. I want to quickly describe what my office looks like and how it got that way.
My favorite product manager I have ever worked with treated the development group with a sort of benign neglect. He spent most of his time outside of the office talking with customers. Randomly, he came back to home base with a blast of feature ideas. Some were well thought out and describe, others were a sentence or two. These ideas got passed on to a developer to turn into software. Somehow, he was usually happy with the results whether we knew what he wanted or had to make guesses. After that, he was off for another round of customer visits and generally inaccessible during that time.
He was my favorite product manager to work with, but probably not the best. So, what makes a good product manager?
I was at an important cusp about a month ago. One big contract was ending and I had till the end of the year to get something new lined up for 2018. Nothing was in the queue and it was stressing me out. There is low demand for non-technical testers working mostly remote and traveling to work on-site occasionally. I am somewhere in-between. I can learn an API, build page objects, and write automation code, but I’m not a full blown SDET type person that can also write tools on the fly. Currently, at least.
The idea that someone can ‘just’ go off at night and learn to program, or any new skill is a myth. This goes for contractors and full timers alike. Let me explain.
It’s December, a time when we gather with family. For a moment or two, perhaps, we think of someone other than ourselves, with a few holiday gifts.
But what about the people in our workplace? The people we spend eight hours a day with, five days a week?
What would the world be like if we took five or ten minutes, and five or ten dollars, to some thing nice for them?
“But Matt”, you say. “I have no idea what to get, or where to start. I don’t know how much to spend, I don’t have a lot of money, and I’d be afraid that it would be weird.”
Start with this blog post.
I am in a local Slack channel for software developers. There are individual threads for everything you can imagine all the way through mechanical keyboard enthusiasts. I tend to follow the quality assurance thread, and the jobs thread to stay on the lookout for work in my area. Nearly every job posted has the text ‘full stack’ at the top of the description. Maybe with the exception of company looking for Java or C# developers.
My co-blogger here on Uncharted Waters, Matt Heusser, wrote an article this week defining the full stack developer based on a RPG point system. I want to take a step back and look at where full stack developers came from and how they are built in the workplace.
The argument of generalist or specialist, or “jack of all trades and master of one” (or some) has been going on in software testing long before I arrived, and may still be here after I am gone. Today I’ll try to find some deep answers about trade offs involved, borrowed from my experience in Dungeons and Dragons.
Let’s talk about wizards and swords.
If you’ve played more than five minutes of any fantasy role playing game, you probably know that wizards don’t carry swords. They don’t wear armor either. Merlin doesn’t carry a sword in the Arthurian legends, Gandolf doesn’t in Tolkein, and even uncle Andrew in Narnia did not carry a sword. According to some lore, casting spells requires hand and body motions that preclude carry weapons and armor … but that’s wrong.
The issue is specialization. Continued »
Tomorrow is Thanksgiving in the US. Many people take off Thursday and Friday to have a day with family and then a day of vacation leading into the weekend. This got me thinking about the hours many technical workers put in throughout the year. It’s always more obvious to me in the winter. People get in early while it is still dark outside to have some quiet, focused time before the rest of the team arrives. Then, when they leave in the evening it is dark again and most of the team has already left for the day. First in, last out.
I put a lot of overtime in early in my career, following that first in last out pattern. I will rarely do that today. Chronic overtime is terrible for a variety of reasons. I have a couple of ideas on why it happens.
DHH (aka David Heinemeier Hansson, the creator of Ruby on Rails) wrote a blog post in the last week about the value of human exploratory testing. Usage of tools to make software development more sustainable has taken a massive leap in the last 5 years. There are all manner of programming frameworks and APIs available, most for free, to help people test code. There has also been a deluge of build and deploy tooling that helps us move from code to a running, testable environment in a matter of minutes or less.
That tooling created a mind shift (or maybe the mind shift created the tooling?) leading part of the dev world to think that they could build smaller, test more granular via tooling, and get away without much of what we call exploratory interaction. This has worked in some domains, but not so well in others. The testers reading this are screaming “I told you so”.
DHH’s post is short, and short on details, but it is important because he wrote it. Development trends seem happen in a pendulum and this might be the beginning of a shift back.
Software development fads come and go every few years, and each time a new trend comes in something is demonized as waste. This time around, it is unit tests.
I was recently pointed toward a summary article explaining why most unit testing is waste. This text mentioned the common reasons for not testing — only tests derived from business requirements have value, too many tests slow development, tests have cost in terms of run time and maintenance, and the idea that tests don’t improve quality. Some of these points seem reasonable, and maybe obvious, but I don’t think they mean unit testing is waste.
An acquaintance on Twitter brought up an analogy in vaccination that I want to talk about briefly.