From what I gather, Google hiring practices tend to be heavy on credential requirements and programming tests. That doesn’t exactly reflect the results of this project. So, how do we cultivate good hiring practices? Or at least, hiring practices that build capable teams?
On board is something technical people don’t seem to think about very often. Bigger companies handle this through the Human Resources department. There is probably a handbook and a series of videos explaining step by step what to do with a new person. IT builds new computers based on employee profiles so that everything is setup on the new person’s first day. The startups I have worked with didn’t have any of this. I had to get my computer setup and figure out what systems I needed access to when someone pointed me to a URL that I couldn’t log into.
I am starting the new year with a new gig, and that reminded me of some of my preferences for the first day on a new job.
It wasn’t too many years ago the world discovered Selenium IDE, the record/playbook tool the runs for free in the browser. Click, click, click, verify that this result had that value, and testers could suddenly create automation … of a sort … in FireFox. It quickly became the favorite browser extension of many a tester. Then again, it was the only browser extension of many a tester.
A few years after that, James Whittaker suggested the Heads Up Display (or HUD) for testing at the Google Test Automation Conference. That discussion starts about 49 minutes in:
It’s been some time since Whittaker’s talk. The Tester’s Heads Up Display never quite materialized, but we can build our own. That is, we have tools that pop in, pop-up, insert data, and show things that are happening on the browser that usually require acrobatics in the web developer tools console.
Here are a few of my favorite browser plugins, primarily for Chrome, all at no cost.
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 »