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.
When people create project plans, requirements, and other documents they often use a template. A template makes things easy. The author can fill in the project name, the date, who they are, the stakeholders, the technical team, the dependencies and the risks. At some point the author has to fill out the big box in the middle about what to actually do, but it’s easy enough to put in some fluff and click save. It’s even easier with tracking tools like Jira, LeanKit, or Pivotal tracker. No writing skills required.
Except we all know they are required. Describing what to build or how to build it, and communicating in a way that the other party actually gets is a skill. It can be done better or worse. Verbal communications is a skill, too, but that’s a different post.
Today I’d like to write about writing, with a few quick wins to develop writing skills. Continued »
Company building is hard. You have to decide what you want to sell and hope there is a market of customers out there large enough to make the money you want. There are the internal decisions of deciding how to build the product, figuring out who the right people to build it are, oh and how to pay for everything. Most companies aren’t making money right away, or even for a few years, so there needs to be enough financial support around the business to pay employees.
Venture Capital companies, or VC, help create that financial padding. They also act as a growth catalyst by pumping a bunch of money and some new goals into a company. Those new goals according to this article, and a story I want to tell, can kill a company.
Most of the people reading this will be familiar with the idea of “management by butt in seat time.” That’s where the manager cares when the workers get into the office, how long their lunch hour is, when they go home, and how long they spend at the water cooler or in the rest room. That’s not exactly the best way to manage knowledge work.
Indeed, you’ve given a little rant at the water-cooler, or, if you are less safe, in the car on the way home, on how terrible a practice this is.
But what can we do instead?
Let’s talk about a better way to manage knowledge work. Continued »