3 ms·
Better, but only slightly. At the extreme other end from pairing, I worked very independently. I had a nice system worked out for how I like to organize reposit
by grappler 13y ago
Better, but only slightly. At the extreme other end from pairing, I worked very independently. I had a nice system worked out for how I like to organize repositories, data, logs, installations etc. That takes some setup work but it pays off for me if I'm able to organize things this way up front.
I was thrilled at the hands off treatment I was getting, as I read documentation and integrated each new piece of the system into my development environment. I would have occasional questions when I ran into something that seemed off, like incorrect documentation or a broken script. I methodically fixed these things as I went, and soon had an automated build that could set up all the pieces on a fresh computer.
Then I hit a snag. I had trouble running the tests. I had little experience with the tool in question and, as has been my habit, took that as an opportunity to dive in and learn the tool. The manager saw this and was not happy. “Just make it work”, he said. “That's not a tool to learn, it's one to get working and then forget about”. I wasn't sure how to act on this. I've fought with code before, randomly trying things until something improves and I find it stressful and unrewarding. I tried to skim more and try things quickly but I still ended up with a lot of documentation tabs open and a lot of material to read and absorb.
The manager became more involved. He found a sample project online where somebody got this combination of tools working together, and sent it to me as I was driving home. He also suggested the probable heart of the matter. I tried it as soon as I got home, and his suggestion was indeed the right one.
I had flailed for a couple days on this, even considering switching to a different tool (an idea first rejected, then later embraced, by this manager and the other developer on the project). For a while, I was dealing with issues myself as they came up, but now with this issue, the things I was reading and trying were being closely watched, and I felt pulled back and forth between different avenues to pursue.
The following morning I was integrating the manager's solution, getting ready to commit. He was already continuing the online exchange. The thing he found was in the comments on the project's home page. It was one of the first things I should have found and tried, and I had missed it. He didn't need to say this; it came through loud and clear in his tone. My stock was falling fast.
The next workday I got an email from an upper manager: please meet this afternoon. At that meeting, I was let go.
I'll never know for sure, but I believe at least part of this was about personality. After spending some time and effort learning a tool, and considering switching tools, he decided I wasn't the pragmatic fast-mover he wanted. I didn't change direction fast enough based on his early comments about how I should approach snags I ran into.
Honestly, if I had seen this happen to the guy next to me, rather than been the target myself, I would have been walking on eggshells afterward.
Sigh, time to go try and be perfect again.
- mcherm 13y agoGood managers give their employees either advice and oversight or autonomy and empowerment recognizing when each is needed to get the job done as quickly as possible. Truly excellent managers do so in such a way that the employee develops and improves. Hopefully you'll get a manager like that. Oh, and stop trying to be perfect: it doesn't work. http://moz.com/rand/expectation-of-100-percent/ http://moz.com/rand/expectation-of-100-percent/
- grappler 13y agoI'm thinking now of how nice a time the person replacing me at that last job is going to have. They'll try the documented way to start services and run tests, and those things will work on the first try. You're welcome, whoever you are :)