Now We’re Getting Somewhere
I think that in these last two weeks, I’m finally starting to figure out the answer to one of my least favorite interview questions: where do you see yourself in x years?
I think the problem, in my case, is that my technical skills always shoehorn me into a developer’s role, by default. However, doing things like building Windows forms and web forms here and there doesn’t satisfy me. It’s not challenging to build point solutions here and there.
One thing that I like about being a consultant is that I get to see many different environments and I get a chance to see how many different companies operate from an IT perspective. When I engage a client, I always end up thinking “big thoughts”. I inevitably share my “big thoughts” with others and (you’d think I would learn my lesson by now) always end up with the short end of the stick, one way or another. Thinking “big thoughts” as a consultant isn’t always a good idea for a number of reasons (or more accurately, sharing such thoughts with the customer); it inevitably leads to strife between the established developers and architects. To begin with, the business of thinking “big thoughts” is typically held by an employee of the client or by a less technical, more senior “architect” (either consultant or employee).
The problem with the former is that you rarely encounter an employee in a non-software related industry that really keeps up with the technology that changes so rapidly around them. Often times, companies are slow to move to newer technologies. There are companies that only switched from ASP to .Net in the last year; they’re 3 years late to the party. Not only that, working within one environment for so long to be trusted with the role of “architect” typically means that one becomes too engrained in the ways of thinking of the other developers within the organization so there is a resistance to trying something new; there is a resistance to improving upon designs limited by weaker frameworks of the past. Instead, the new development is inevitably shoehorned into the “traditional” way of thinking (“this is the way we’ve always done it” (incidentally, this is what Scott Bellware meant to address when he coined the term “Visual Babytalk” (It’s not that I have anything against VB.Net, in fact, I have a workshop written VB.Net, it’s just that the majority of the developers that think in VB are from an antiquated era of software development))). A developer that wrote the last system in ASP+VBScript is going to be a bad choice to design the new system which will be implemented in ASP.Net+C#. The radical paradigm shift in architecture isn’t apparent to many and most implementations end up being little less than .Netified versions of the old ASP applications using the same principles that were used when writing ASP. Yuck.
The problem with the latter is that more senior architects are typically less technical or they’ve strayed from their technical roots. Without a deep understanding of the technologies that are evolving, there is no way that good software design can arise. It ultimately ends up in a design that mirrors last gen. thinking. Now I’m not saying that senior architects can’t design good systems. It’s rather that there are so few architects that remain technically rooted in the latest technologies and software design principles (of course this is not to say that there aren’t fundamental, “old school” principles that still hold). A part of the problem is the business model where a management position is equated with higher salaries. So instead of equating a higher salary with a more technically sound and educated developer, companies like to promote and bring in new developers (employee or consultant) that already know the new technologies. And let’s face it, people have lives. As you progress in life, you will have children, you will have a house to take care of, you will have multitudes of responsibilities that distract from your ability to focus on studying technology and design principles. It’s an issue I fear I will have to encounter in the next 5 years (and I thank my wife for taking a big burden off of me by taking care of most of the day-to-day responsibilities like paying bills and that sort of trivial stuff).
Now don’t miscontrue my words; I hardly think that I’m “The One” or anything like that. In fact, I openly admit that I still have much to learn. When I say “big thoughts”, I simply mean to think beyond satisfying immediate needs. It’s the difference between giving a man a fish and teaching a man to fish. It’s the difference between putting a bigger, more powerful engine into a below average car in hopes of driving sales versus building a better factory and hiring more skilled workers which will yield higher quality. It’s the difference between trading for a basketball player that averages 5 points per game more to try to win games versus rethinking the offensive and defensive schemes to improve the chances of winning (i.e. Dallas Mavericks). It’s the difference between designing a processor with a higher clock speed versus designing a more powerful processor (Intel Pentium IV vs. Intel Pentium M/AMD). It’s the difference between thinking 2 weeks into the future and thinking 2 months down the line.
So I think I know what to ask next time I go into a job interview: does your organization like to think big thoughts? I don’t want to sit around writing reports or tweaking Windows forms. I want to write the framework to help the developers more rapidly write and deploy the reports. I don’t want to sit around tweaking Windows forms every time a business person wants to change a layout. I want to write the framework to allow for an easy to reconfigure UI. I don’t want to do trivial programming tasks. I want to build complex things. I don’t want to work under a technical architect/lead developer who’s less technically educated than I am (I make a distinction between technical architect and business architect/analyst) unless said individual is open to new ideas, new technologies, and new ways of thinking. I like to think “big thoughts”.
My managers and the customers (business people) don’t always like that. Managers think small thoughts. They’re like children in the sense that they have short foresight. Part of that is that they’re at the whim of the business people and in the eyes of the business people, if you’re not contributing to the bottom line today, you might as well be gone tomorrow. They’ve been conditioned to operate in a mode where quantity is valued over quality, where getting it done now is more important than getting it done right. When you work like this, what you end up with is a pieces of code that are cobbled together, difficult to maintain, and costly to fix.
Unfortunately, very few managers that work outside of software related industries think big. I don’t think that I’ve ever met a manager that I would say “thinks big”, but I think I’ve come close by having managers that allowed me to think big by trusting me and allowing me to work the way I like to work.
I remember telling Brian, my current managing consultant, that I like to work on things that don’t have value. More accurately, I like to work on things that don’t have immediate value. The value of such things is never apparent in the short term, as in the short term, the paying customer wants to see progress. When building such things that have little immediate value, it’s very difficult for the customer to understand that if a little more effort is put in upfront to solve the more complex problem, then it will be many times cheaper to solve the simple problems down the line. Writing a framework to create and distribute reports costs a lot of money upfront with little to show for it. But the benefits down the line far outweigh the immediate costs as report after report is written and deployed using the framework (and it’s not like a business is going to ever stop writing reports).
It’s unfortunate for me that I’ve never really worked in a software
development company as I think that’s where I’d fit in the best. But
at the same time, I think if I did work for a software development company, I wouldn’t be exposed to the complex business problems that people are trying to solve. But for sure, I now understand what I want to do in the next 3-5 years: I want to solve big, complex problems.
On a tangent, I think I’ve figured out why I have problems making small talk and chit chat. It’s because I don’t want to talk about anything other than software design, technologies, and the process of building software 😛 Seriously, that’s really just about all that I’m ever really thinking about when I’m not watching basketball or doing something mindless.
I guess I’m just ranting now 😀 The problem is that I’m thinking big thoughts, but mired in a situation where I’m forced to work on small ideas. It’s terribly frustrating, to say the least. I feel so un-energetic each day. :-S
