I read an indictment about work culture in the Silicon Valley last week. This article describes companies where employees working what used to be normal shift, 9 to 5, are now thought of as losers. Venture Capitalists throw money at founders who throw far less money at impressionable people. These people work 50 or 60 (or more) hour work weeks under the impression that they are building something important, or that when a liquidity event occurs they’ll get rich. The reality is that the VCs get rich sometimes, the founders get rich less often, and everyone else never gets rich. Never.
Work-life balance problems, and taking advantage of the good will of ambitious people is not a silicon valley problem. This happens anywhere you find software. I of course have my own story.
Most of the process I have experienced in my last several years while working at software companies was designed to create the illusion of speed to market, but very little actual speed. The development teams get a sprint backlog of entirely too many changes, work their way through them by spending too many hours in the office, and them move all the cards over to ‘test’ in JIRA. Testers get a few days, get through as much as they can and then the release date comes calling.
The teams I see going faster, have slowed down.
I spent most of last week helping a team of people run a software testing conference. The 10 months leading up to last week were spent hunting down venues and doing negotiation on rate, looking at hotels, reviewing catering, coordinating with speakers, and all of the million things that go into putting on a conference. Our event was 4 days in total. We kick off with a day of tutorials, that is followed by two conference days, and then there is a post-conference event on the last day for a smaller group of people.
This was my first time being so involved in a large technology event, so of course I have a few thoughts for other people that might be doing this in the future.
One of the questions was “What does good software testing look like?”, which I found fascinating.
Take two teams. One has strong tooling that runs for every commit, that scales out to a grid of 256 simultaneous servers, giving feedback in five minutes. Another team has a component architecture; they make small changes and deploy them independently. The second team has high confidence that a change only impacts that one component, automated “contracts” to check correctness, but no end-to-end GUI checks. Instead, team two does the rollout, checks a few flows in production in a test account, and relies on incremental rollout and intense monitoring to find problems.
Both of these could be excellent software testing in context. For that matter, good testing for a pacemaker or avionics controls could also look very different. I want to describe a model, a sort of checklist, to see if testing is “good”, and what gaps exist.
Between the question and lightning talks later that day, I came up with BRR I TV. Continued »
I got a phone call from a technical recruiter last week. These calls are usually painful, but I had a couple of minutes and could use some entertainment, so I took the ride.
The recruiter said she had a remote testing position available and had found my resume in their database. I haven’t kept a resume in several years, so how she had that is a good question for another day. She started asking me questions, and I felt like I was running through a check list. Can you program in Java, how many years experience do you have programming in Java? Can you write SQL, how many years of experience do you have writing SQL.
Luckily the call was short, maybe 10 minutes in total. I didn’t perfectly line up with the checklist, and the company this recruiter was representing was low-balling on the hourly rate, so we said goodby and parted ways. This 10 minute phone call reminded me of what I like in good technology recruiters.
I had a breakfast meeting today with a local tester / manager type person that has recently decided to venture out and build his own company. He was working as a test manager for a company in another state and over time the company decided that role was no longer necessary. Over his tenure, he built up a practice group, broke up the independent test group and moved testers to development teams, and built a sustainable model.
Of course, once the teams were merged with development and had learned to sustain themselves, there wasn’t much need for full time management.
Last week Justin Rohrman took a crack at the Freelance Rate Myth. It’s a good read. It made me want to take a swing at another classic, overly simple freelance idea: “Every year, fire your bottom-paying 10% of clients so you can hire new, top 10% clients.”
It sounds great. It is attractive. I have heard it preached by probably half the people I talked to about my freelance portfolio in the past five years.
The only trouble is, it doesn’t really work.
Here’s why, and an alternative. Continued »
In June I wrote a piece about what life has been like for me working as a technology contractor. This was mostly focused on the myth that all of contracting is the wild wild west. You have to be prepared to lose your gig in a moments notice. While that might be true for some people, that hasn’t been my experience.
This week, I want to go a little deeper into freelance/contractor mythology and talk about bill rates.
The literature I read gives one point of advice here; if you want a raise, raise your rates. There are even books and conferences names after this piece of advice. Logically, that pithy quote makes perfect sense. But in practice that just isn’t how freelancing works.
Extreme Programming gave us pair programming, a practice that is incredibly successful, wonderful beneficial … and hard to adapt culturally. Instead, people say they “pair when it makes sense”, which is code for “every now and again over a lunch hour”.
The main objection to pair programming is efficiency — it feels like two people doing the same job. If the pairs were split, development would be twice as fast! I can’t agree with that logic, but that is not today’s post.
Instead, today’s post is about effective pair programming when half the pair is a tester.
That’s can be scary, but with a little effort, testers can be incredibly helpful in pairing. Here are some ideas. Continued »
It is hard to point to an exact reason. It could be market saturation, the intersection of price and willingness to pay, lack of companies that want to hire people at that skill level, or coding schools graduating people that aren’t capable of doing software development work. Many of the sentiments I am seeing online right now point at the latter. People seem to think that the quality of the students graduating from a coding school just isn’t very good. They are on the verge of being self-taught, and don’t understand enough of the important concepts to be successful in a development job.
Well…duh. How good would you be at anything after 12 weeks of introduction?
I think this points to a different problem in software.