And I felt a bit better. Because if Neil Armstrong felt like an impostor, maybe everyone did. Maybe there weren’t any grown-ups, only people who had worked hard and also got lucky and were slightly out of their depth, all of us doing the best job we could, which is all we can really hope for.
And, of course, there are experts stating out loud at conferences that they have no idea what they are doing, and encouraging everyone else to stand up and agree.
Here’s the part where I get in a lot of trouble.
You see, when I hear those appeals, I remain seated. I have the audacity to believe that I actually know what I’m doing.
I know. I must be some sort of narcissist, right?
Working from anywhere that isn’t an office, or remote work, has been a popular topic lately. IBM recently decided to end its remote work program. More than 2,600 people will have a choice between relocating to a city with an IBM office, or finding work elsewhere. IBM is citing effectiveness and efficiency as the reason for this decision.
I have been working remotely for pretty close to half of my professional life. I was at home from 2011 to 2013 and then again starting in 2015. I have worked with teams that are all remote, and with teams where some people are in the office and some do their own thing. Here are a few opinions I have developed over that time.
Asking for a raise sucks.
My pattern is usually to spend a few days or weeks brooding over what I’m making. One day after getting psyched up, I finally ask. The answer usually relates back to having to check the budget to see where things are, or a reference to a hiring and compensation freeze, or the always comforting “I’ll get back with you”.
Asking for money is a game of strategy and power. I have a two part strategy for asking for raises.
Today’s programmers jump from tech stack to tech stack, learning Ember-React-Angular today and a CSS Compiler Compiler tomorrow.
No really, that’s a thing.
What’s a technical person to do to stay active and marketable in their 30’s, 40’s, 50’s and beyond? Continued »
I was talking with some people in a Skype thread about a conference pitch. The theme of the pitch was acceptance testing driven development (ATDD), and one of the points mentioned as a take away was having a better understanding of ‘shift-left’. Shift Left is the idea that testers should develop a skill set that allows them to get involved in testing much earlier in the development cycle, and also that companies should create a culture where that is possible.
One person in the thread had a gut reaction and claimed that they hated the term shift-left. They dismissed is as nothing more than a buzzword people use to get talks.
I think buzzwords are meaningful, let me tell you why.
We picked up the latest generation of the Amazon Fire Stick about a month ago. We had been using the previous generation and were happy with it. My mother in law wanted to be able to watch PBS shows while babysitting my son, but her Samsung smart TV doesn’t have any PBS apps available. We installed the first gen Amazon Fire Stick over there to solve the PBS problem, and ordered the latest version for our house.
We have been using the new Amazon Fire Stick for a month now and have some initial impressions
I was talking with a friend last week about some shakeups at the company he is working for. This is a fairly well established company in Nashville, but they aren’t profitable yet and are in the process of taking another round of funding. This friend is seeing some instability in the company and is thinking about moving on to something else.
I’ve been through three or four of these funding rounds now while working at startups and have noticed some patterns. Maybe my experience will help you decide if you want to stick around, or move on.
McKinsey & Company, the world’s predominant consultant on management by the numbers, had a famous insight known as the “general survey.” The company analyzed every step in the value chain, from taking the order to creating the product and shipping it; they then looked at cost. They basically wanted to find a way to do everything cheaper. A way to outsource product development, centralize marketing, find cheaper workers, find cheaper supplies, and eliminate transportation costs. To any management that is looking to boost profits, cutting expenses in half sounds like a good idea.
Except when it doesn’t work.
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.