leadership – Preston Lee's Blog

Handling Self Doubt

I’m an engineer. Always have been. I cronically worry about small flaws which could spiral into unsalvagable disaster, and spend a great deal of time focusing on risk mitigation. I can thus completely identify with Riyad’s “cronic almost-achievement” issue because I felt like a raging victim of self-imposed mediocrity up until several years ago. I realize I can be harsh in self-judgement, but nevertheless came to several conclusions..

I have tons of great ideas that aren’t going anywhere. (..or worse, are getting somewhere but at a pace slower than the end goal is moving.)
I really don’t like being told I suck.

Any leader that says they can completely shrug off even the most meaningless criticism is full of crap. Putting yourself on the line by saying, “I did something. Check it out.”, dangles your ego over a boiling pot of water. You know the potential for greatest is there–you wouldn’t have done it in the first place if you thought it was a bad idea–but your heart still sinks when you’re about to demonstrate your competence level to the public at large and have absolutely no guarantees on the outcome. Ego roulette is clearly not an engineers game.

…but then, I decided to change.

If I have a great idea and the time/resources to pull it off well, I’m going to look fear straight in the eyes and tell him to STFU.
I’m done with looking back and saying “I should have done more.” Whether it’s writing about a controversial opinion or pulling people out of a car wreck, no more inaction. Maybe I’ll collect an inbox full of hate mail or painfully burn to death in a firey explosion. So be it. At least I tried to change the world and did my part to the best of my ability. “You must be the change you want to see in the world.” –Mahatma Gandhi.

Now, I still have the same self doubt and self confidence issues at the next guy, but I finally feel like I’m doing something about it. And doing something is an engineers mantra. I’ve you’ve really got a great idea, it’s infinitely more important than your fragile ego. Here’s a couple of thoughts that may help entrepreneurial pessimists like myself..

If you screw up on project XYZ, no one is going to care in 5 years. Take the small wins and build on them. It’ll feel good.
What’s the worst that can happen? ..people will laugh at you? …you’ll loose your investment? …you’ll have to go back to your day job? Are those the best reasons you can come up with? Really!? *Please* … If you’re reading this you’ve got food, water, shelter, internet access and probably some good folks to lean on should things get tough. That’s more than most of the worlds population, so quit whining on the $10K it’ll take to do that new project and take a calculated risk. Even failure can feel good when you know you did all you could. You’re going to regret it if you don’t.
Criticism is the easiest form of feedback, so there will always be haters and sometimes more negative commentary than positive. Learn to extract the meaning from the negative feedback, remember that those with the loudest voices don’t necessarily represent the population, and make it an opportunity to hone your game rather than pity yourself.

Identifying Senior Software Engineers: Six Critical Differences

For HR and legal purposes, most development companies classify Software Engineers into ranks from I to IV (or V). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.

While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How do you objectively identify ‘senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.

Instinct

He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..

how complicated the code is.
where potential bugs are.

Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.

Foresight

Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)

Results Focus

Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.

Communication

New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives. The criticality of non-verbal developer communication is also apparent to the senior engineer. For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present, because not having clear priorities and documentation introduces roadblocks to results.

Time & Priority Management

A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.

Estimation

New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit to a workload than a senior.