Preston Lee's Blog

Month: August 2008

  • 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..

    1. 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.)
    2. 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.

    1. 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.
    2. 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.

  • Need Monitor Color Profiles (.ICC Files)

    OpenRain will be launching a simple, online .ICC monitor color profile database shortly, and is looking for .ICC file contributions generated with hardware colorimeters. We’re also looking for administrators/moderators to add display models, remove bogus content, seek out .ICCs for missing models and suggest new features. If you work in the computers or graphic design space and would like to get involved for the sake of design professionals everywhere, hit me up!

  • Installing The MySQL Ruby Gem When Using The Official MySQL .dmg

    If you installed MySQL using the official .dmg package provided by MySQL AB/Sun and are trying to install the native MySQL gem, you’ll need to pass a bunch of flags to the gem install process to get the thing to compile. Try this..

    sudo gem install mysql — –with-mysql-config=/usr/local/mysql/bin/mysql_config

    ..if you still have issues (check your /opt/local/lib/ruby/gems/<ruby_ver>/gems/mysql-<gem_ver>/mkmf.log file), try this instead..

    sudo gem install mysql — –with-mysql-dir=/usr/local/mysql –with-mysql-include=/usr/local/mysql/include/ –with-mysql-lib=/usr/local/mysql/lib/ –with-mysql-config=/usr/local/mysql/bin/mysql_config

    Run `sudo gem install mysql` and definitely recheck the log file again as the gem install process sometimes reports false positives even if native components fail to install.