We don’t do deliberate practice enough as programmers. Instead, too much of our time is spent trying to get the next piece of work done. Perhaps we’ll clean it up tomorrow. Perhaps we’ll do it right next time.
Perhaps monkeys will fly.
Instead of trying to clean it up later, I recommend developing skill outside of production code. The Kata is one way to do that. CodeKata.com describes them this way:
“A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long).”
Today I’ll talk a little about Katas in Ruby, how I set them up, what they are good for – and the kata generator tool I wrote. Continued »
A few years ago I was working with a development team at the end of a very long release cycle. About 15 of us were gathered in a meeting room giving our status update. Most of the developers said they were done with implementation and were either waiting for feedback from testers, or were going to start looking at the next sprint. The rest of the developers were still working on building features for this release.
After everyone gave their updates, the manager said we were about to have a code freeze. No more checking in code.
Developers were still implementing features, testers were still finding bugs that would probably need to be fixed, and we had not produced a candidate build yet. But, out manager said we were going to have a code freeze.
Over the weekend United Airlines overbooked a flight. They chose a few people, who had already paid for their tickets, to remove from that flight so that United employees could board as standby passengers. This is the age of cell phones, recording public life, and social media. Twitter, Facebook, Reddit, and news sites were flooded with the video of a man being dragged from the United flight. By Tuesday morning, United stock had dropped by $1.4 billion dollars. Yes, billion.
Social media is a powerful tool that some companies use for marketing and product support. Other companies are destroyed by it. Many technologists I know use social media heavily to build their personal brands.
Every company I have worked for has a spectrum of employees. The people in the middle get their work done quietly. They do a good enough job, generally get things done on a deadline, and don’t make too much of a fuss. At the bottom, the low performers, are the people that you’d rather not work with. These folks do a poor job in general, they forget important parts of the project and are late with most of their work.
At the top are the high performers. The high performers get their choice of the newest and coolest projects, they raises and bonuses when the company is on a hiring freeze and there is no extra budget, they get sent to conferences, and are on the list of people to be groomed for when a management position opens. The high performers get the attention and adoration of management.
Have you ever seen a poor neighborhood suffering from a lack of funding in education and infrastructure?
This is a similar problem.
Most of us are familiar with the iron triangle of quality, speed, and price – pick two. Some people extend that to four elements, including scope. Yet there is another, deeper dichotomy, the tradeoff in life between comfort and happiness. To many of us get it confused, equating the two as the same.
Today I will argue that nothing is further from the truth. If you want to be happy, you’ll need to be uncomfortable – the right kind of uncomfortable.
Earlier in March I wrote about the difficulty of working through cost trade-offs. A team I am working with was trying to decide the best way to create an environment for nightly run of a UI automation test suite. We decided on a solution. Our IT person created a clean virtual machine and gave me admin access, and I installed the tool we are using for automation. I logged into the virtual machine, set everything up for the nightly run and called it a day. When I logged in the next morning, nothing ran.
I spent the next day and a half scouring the internet for documentation that might explain what had happened
According to this post on ITKE, I have nine years before I start retiring from technology.
The fact that software is dominated by people just out of college is not a secret. Walk into any software company and you will see that. Developers are in their 20s for the most part. The more grey hair a person has, the more likely they are to be in a non-technical role. There is a lot to unpack in this scenario. Large companies are enacting policy that actively discourage people with families from working there. And much of the software being developed today is just simple. You don’t need a team of senior architects to develop a marketing website or a new plugin for WordPress.
What do you do when you only have 9 years left?
A good example is the word ‘break’. Sometimes I like to say testers break stuff. Often it is with humour. Virtually everytime I use it, or when I see others use it, then a tester pops up correcting the use of the word break and how testers don’t break things. The same applies to other words. QA/quality is another example. Or testing/checking.
It’s all good discussing these things, but it feels like it has gone over the top.”
– Rosie Sherry on the Ministry of Testing
Yes, most testers do enjoy a well-timed “Well, Actually.” To some testers, “Well, Actually” is the job itself. Consider the programmer, who spends a week developing an amazing report. The tester adds value by saying “well, actually, sort order is broken if …”
Personally, I find sometimes testers do break things. And sometimes, the distinction between QA and “testing” doesn’t make a difference.
Let’s talk about the definition game. Continued »
I read an article on Harvard Business Review this weekend that described why companies investing in employee engagement get so little in return. The concept of employee engagement is vague, and I can’t seem to find a clear definition or a simple way to measure it. So, for the sake of this post, let’s say that employee engagement is how committed an employee is to a company. Or put simply, how much someone cares about their employer.
This HBR article is based on research performed across many different companies. I don’t have research, but I do have anecdotes that compliment the story.
I am working through a tough technical cost trade off decision with my current client.
Our nightly test automation has run from my local machine for the past year or so. There are some obvious challenges there — I can’t use my computer for other work in the evening, tests are subject to the whims of my local internet connection, and the occasional Windows update that makes my computer a zombie for an hour. We have three decent options of how to proceed.
Programmers sometimes like to pretend that there is a clear cut winner in our technical solutions. In my experience, everyone has a different cost and we pick the one that seems the least painful.