Aug 30, 2012

Viking laws for tech teams, part 2: keep yourself in shape

This post is part of the "Viking laws for tech teams" series.

Skills, attitude, stamina: the iron triangle of survival in challenging environments.

No skills? You're dead weight, no one will ever want you on their team. Rusty or outdated skills? If you're lucky, you may get a job maintaining legacy systems… until they're shut down or outsourced. Bottom line: if you think you were done learning when you left school, think again. You should never stop learning: blogs, books, personal projects, conferences, anything goes. Don't let your edge grow dull, keep it razor sharp.

Example: 40-year old embedded software engineer who decides in 2001 that he doesn't like object-oriented languages and that he will keep writing assembly and C language for the rest of his life. Fast forward 5 years: ALL projects now include embedded Java applications, which junior engineers can write and debug with their eyes closed (for half the salary). Game over. The guy barely saves his ass by accepting Quality & Documentation tasks: not what he had in mind, but still useful and way better than being out of a job at 45 with two kids.


Poor attitude? You might fool the team for a while, but you'll end up being thrown overboard. You need to truly believe in what you're doing and give it your best shot. It has to be more than "just a job". No, this isn't about lapping up corporate bullshit ("work hard, have fun", you know what I mean). It's about standing your ground, soldiering on, delivering the goods, being someone that your buddies can count on in good and bad times alike. Ask yourself: when the time comes to leave, will I be able to look proudly at what I've helped build over the years? Two years later, will I be remembered as the tough-as-nails engineer who got shit done, no matter what? Will my code still run in production? Yes? Job done then, with plenty of good memories and war stories to share. Nothing else matters.

Example: that last guy who joined, left after 6 months and that no one remotely remembers. Which is the way it should be.


No stamina? You might be the sharpest, nicest guy around but you won't last. It's not about long hours, nights or weekends (yes, they're sometimes needed). It's about enduring the daily insanity of fast-paced projects: 180-degree turns, showstopping bugs 2 days before the release, supplier issues, customer whims, management stupidity… The list is endless. If you blow a fuse at every roadblock, you're bound to waste energy, grow tired and lose motivation, so whatever you need to do to vent off, do it regularly. Also, never ever lose your sense of humor: unless your code runs in nuclear plants, airplanes or hospital life-support systems,  it can't be THAT bad, so stop being a miserable bastard and just try to laugh it off (even if it's damn hard sometimes). Remember: it's not a sprint, it's a marathon, a 40-year long marathon. You won't make it without nerves of steel and a healthy dose of self-derision.

Example: the burnt-out, negative, cynical guy in your team who used to be a super achiever and a great guy. Do him a favor and let him go.


Bottom line: it all starts or ends with you. Take care of yourself, but keep pushing your own envelope. Don't pretend, do it for real: the more you sweat in training, the less you bleed in combat.

Please share your comments or anecdotes. See you next time.

2 comments:

  1. Yeah, well-judged!

    Except the first example which is wrong: NO, all embedded projects are not today including f*ing Java! We lack guys that know how to write real C, debug in assembly and are able to allocate a piece of memory aligned on the CPU cache lines... Java has always been for the pansies and if you do not believe me, come on for real dude programming with performances underneath.

    You should not enter that "google-like" cool and sickly attitude (and do not throw good engineers in QA).

    But I got devices to burn and bits to fly! The next coding challenge... is just... around... the bend!

    See you pal.

    ReplyDelete
  2. Ah, my example wasn't clear enough. I'm talking about one my previous companies, where all embedded projects DID end up involving Java apps.

    I agree with everything else you said. Actually, you sound like some guys from my team and I'm sure your comment will be mentioned at the coffee machine tomorrow :D

    Thanks for reading and sharing. Stay tuned for much more and keep the True Embedded Faith alive, my brother!

    ReplyDelete