You might be noticing a theme…
This is a huge issue for me. We have wasted so much time on bad hires when it comes to our contingent workers. Having learned from experience, we no longer bring someone in if anyone on the interview team has any bad vibe about the individual. Apathy is a no vote as well. Everyone has to agree the person is additive or we don’t bring them in. It is better to be understaffed, know our limitations, and keep the code clean than to bring in someone that will only make things worse.
PS: I just finished another phone screen. I voted him down in under 10 minutes. After he couldn’t answer the second technical question, I didn’t see any point in continuing. We did continue, but it only took another 5 minutes for everyone else on the team to agree. Thanks but no thanks.
One of the few areas where I agree with Jobs. The bozos need to go. From my experience, these people tend to be project managers, business analysts, and super-users. In other words, people who think they know how to do my job, but really don’t have a clue who to write software in an enterprise environment. I don’t know how many times I have heard “Ya know… I used to code too.” Queue the eye roll. “Really, if you were any good at it you’d still be doing it which is why you’re not programming any longer. Right?” I am PC enough to not say that out loud (yet), but I have started heckling the people that use that line on me in more subtle ways. “Ya know… That headshot makes you look like a salesman. Exactly what are you trying to sell?”
Something else I read recently in a Neal Stevenson book, Reamde:
A’s hire A’s. B’s hire C’s
Which kind of explains why we have such a hard time finding the right contractors. I wants As. I don’t want people to stroke my ego. I want people that can write kick-ass code while conforming just enough to allow their code to be supported in the long-term.
It’s even better when they can teach me something.
I’m allowed to dream. Right?
I’ve been working on a series of POC projects that all went live with little time to pay off the technical debts incurred when converting a demo app to a production app. The time is finally come to start paying off the debts. This week, I’ve been refactoring an app to be DI. Last month, I had to rewrite an app basically from scratch.
We have 4 projects in flight as of this morning. I think it is 2 web apps, a WPF dashboard, and a VSTO add-in for Excel. We released another VSTO add-in a few weeks ago. So I think we are sitting at 4 apps. It might be five, if something spun up while I wasn’t looking. I am now managing code quality for all of the developers. With the expansion of our team to 11 + 1/2, my time has gone from 80% research, 10% support, and 10% teaching to something more like 50% code reviews/teaching, 20% support, 30% research thru refactoring. <ugh/>
The single most important topic is supportability. If you are writing code that doesn’t conform the general shape and style of our other pre-existing apps, I will make you redo it. The problem is where extra person has to (re)learn an app every time we get a support call. I’m trying to reduce friction so that we can get into the code, have a good idea or what’s what without spending days trying to understand the app, then make our fix and get out. To that end, I can’t let anyone slide on code quality. I have to be a dictator about it. “You will do it my way…” I hate managing people like this, but it has to be done. The alternative is very unpleasant.
Keep in mind, we have something like 17 apps already in production. Some of that code is crap. But… There are a lot of good ideas in there too. My role is now to keep all of that previously acquired knowledge in my brain and pull it out to the betterment of the team. I do this during design meetings (a pre-coding code review), during the weekly team technical meeting, and during code reviews. Doing code reviews was not exactly what I signed up for but I’m the one who cares the most of the 3 Blues.
Hopefully, I’ll hit a good groove and find the time to write more about what I have learned in the last couple months.
I needed to take a stock XAML ‘image’ for a search icon from SyncFusion’s Metro Studio and rotate it about 75 degrees but I couldn’t use the rotate transformation code to do it because all of the required data had to be contained in the path description/geometry.
If you need a reference for how to do a normal transformation, try the Transforms Overview on MSDN.
Last year, I needed to set a logo for a new app I was developing using the ModernUI shell (CodePlex/GitHub). The logo is set in as a property of the ModernWindow as LogoData. LogoData is a raw path. So I couldn’t use anything except the XAML defined geometry to describe the logo. Continue reading Rotating a XAML object without using the Rotate Transformation
It’s a bit weird when I talk to one of my new contractors at 7:30pm then again a few minutes before 8am. He’s only been around for a few days and we have not been in the same physical space, but I’m actually looking forward to getting his input on a number of projects that I have running right now. He seems to be as passionate about “doing the right thing” when it comes to code.
Working code isn’t enough. It’s a starting place.
In case you haven’t noticed, I try to treat my contractors like peers. Having been a consultant/mercenary for well over a decade I don’t see why your employment status should make any difference when it comes to doing your job. The mercenary roll can be very difficult at times. You have to limit your output and emotional investment, because in the end you don’t own the work product. It’s someone else’s baby once it’s been brought into the light of day. I guess you could say that for everything we write that isn’t written 100% during our (non-existent) free time. Intel owns everything I write during the day. My other clients own the code I write in the evenings. It’s the nature of my profession.
I’m hopeful that our latest round of “contingent workers” are going to measure up. Time will tell…
I’ve talked about interviews and team building a bit before in my “team” post. I suppose you could view this as the other side of the coin for team building. The dark, dirty underside… It ain’t pretty and I can admit that I am part of the problem but… By perceiving my role in the status quo, I have an opportunity to change.
Continue reading Interviewing / Team Building