- Posted by Ian Suttle on September 24, 2007
- Filed under General
I've been interviewing and hiring engineers for years and the one saying that holds true in this experience is "it's hard to find good help these days." Not to say there aren't a number of bright individuals with good experience and characteristics out there, it's just they all have jobs already. It literally can take six months or more to find the right candidate for the position. Maybe I'm too picky. I probably pass up some would be good candidates, but I very rarely hire a bad one. I probably couldn't pass my own interview process actually :). Through the years I've come to realize some key traights of good engineers:
- Foundational knowledge - It's not enough to know the textbook on the latest and greatest programming language. You need to understand the fundamentals of software engineering. School may not be teaching you the latest version of .Net or Ruby on Rails, but they're teaching you about data structures, object oriented concepts, etc.
- Relevant experience - Okay, so knowing the textbook is good too. A good engineer can learn a new language and set of tools, and combined with foundational knowledge and industry experience they're now a well oiled programming machine.
- Positive attitude - Negativity is infectious; avoid it at all costs. We all get stressed and frustrated at times but how you react to those situations shows your true character.
- Sense of humor - If you can't smile, I can't hire. A good sense of humor can make up for other imperfections you may have.
- Dependability - Huge. If you can take the baton and carry it through to the finish line you're worth gold. There's a pit crew there for support but you've got to drive the car. Whatever you do, don't drop the ball... or crash the car to stick with the analogy :). It was pointed out by a reader this sounds critical so let me clarify. I define "drop the ball" as being flakey and not as making mistakes. Making mistakes is a natural progression of learning and growing and is expected without lashings in return :).
- Communication - You must be able to understand what's being asked of you and discuss important topics. If you can't, you won't build the right software and you'll mold inaccurate perceptions. Your manager should also be up to date on status, happenings, and obstacles. It's your manager's job to help clear the path.
- Creativity - Can you think outside of the box or do you hit your face trying to find your way out? In the software engineering world no two projects are the same and if they are, well that's what code reuse is for (note I'm specifically NOT saying Copy and Paste).
- Enthusiasm - Love what you do. Learn what's new without your job requiring it of you. Keep up with the latest trends. Work on your own pet projects. If you got in to the "computer industry" for the greenbacks, I predict a change of profession in your future :).
The position being hired for likely has specific requirements and would be in addition to the traights I've listed. Lastly, everyone can improve on all of these aspects so don't give up hope if you think you fall short.
Oh yeah... if you do fit this description contact me - I have a job for you :)
- Posted by Ian Suttle on September 18, 2007
- Filed under General | Open Source
I love the lifelong learner approach to life. There isn't a soul on this earth who's "knowledgeable enough" or who's an expert at all things. God knows I fall very deep into that category. Software developers are lucky in this sense - there are seemingly endless resources available to learn more about a vast number of technologies and approaches.
Open source projects are one of my favorite ways to learn and expand my imagination. I find it almost exciting (nerd) to review open source implementations to see how the developers think and create. Open source projects also add a certain level of design validity - they're under the scope of the community who has the power to comment and improve upon the design.
One site I've been keeping my eye on over the past couple of months is DotNetKicks. If you aren't familiar with them I encourage you to take a peek. Basically DotNetKicks is the Digg of the .Net development niche. Back in July Gavin Joyce announced DotNetKicks had become an open source project. It took me a couple of months but last night I finally downloaded the source and began to dive in to check out the mechanics of the app. I was pleased by the overall organization of the solution, readability of the code, the use of tests, a multi layer approach, and clever integration of a few external open source projects.
If you're interested in continually growing your skill set you should consider going to school on others' hard work :).
- Posted by Ian Suttle on September 7, 2007
- Filed under General | Process
Surely you've received this question from a business stakeholder: "When will my project be completed?" What you'd like to say is "I'm not sure, but I'm working on it" which of course doesn't fly. Software estimations are notoriously difficult to accurately predict. Book after book has been written to explain how to develop an accurate time estimate for software development. Most books are wrought with theories, complex mathematical formulas, and a lot more resource requirements than you've got at your disposal.
Personally, I don't find this a realistic approach in such a dynamic environment as the web. Most engineers I've seen revert to a review of the requirements and simply tag each section with a quick estimate. "Okay, that's an easy form and will take me three hours. This function will be about two days..." In the end you have a tally of wild estimates. Odds are you're going to be held to your timeline so go ahead and tell your life "be back later." If you can look at a single requirement and know it's going to take more than a few hours, you don't have enough details on the task or you haven't broken it down far enough.
So what approach is realistic? Let's start with project scope. Do your homework. Understand what you're building. Often you'll have
to know what you're starting with as well. If that's the case and
you're modifying an existing application be well versed in refactoring
patterns. If you determine the project will require more than a couple of weeks break it in to phases if feasible (see Sprint used in Scrum). The idea is it's far more realistic to accomplish shorter term goals (days, weeks) than longer terms goals (months, years). Think about it. Would you feel more confident in completing a single module or a group of modules within a single timeline? Also keep in mind, change happens. Requirements change, technologies change, resources change, and priorities change; all items likely to be out of your control. By taking on a short term goal you reduce the chances of change affecting your goal and efforts.
Once you've etched out a short term goal, it's time to design your solution. I don't mean create a web site diagram and a flow chart. I mean that and more. Design your database schemas including tables, stored procedures, functions, and relationships. Design your class libraries including methods, enums, types. Design your pages including controls, third party libraries, UI. You're designing how these elements all work together, but remember, just for your short term goal. If you can't design your solution at this level of detail, you don't know what you're building and need to go back to step one - do your homework. However, realize the inverse. You can probably predict with good accuracy how long a stored procedure will take to write. Not only can you estimate a stored procedure but you can estimate a method, class, user control, table, etc. Don't allow any less than an hour or any more than four hours per task. If more than four hours you need to break the task out into more detail. As you generate your estimates document them and track your progress. Don't forget to account for code reviews and project documentation. TFS work items are great, but Excel worksheets can do the trick.
I also recommend having the design and estimations reviewed by a senior engineer with a proven track record of achieving their timelines. This is your check and balance. If you estimate a stored procedure will require one hour of development but it really requires two, you were 100% off. Apply this boo boo to multiple estimates and your two week project can quickly turn in to a three week project. That's a 50% increase in time. Expect you'll have at least some items underestimated. Your reviewer should be able to help you adjust and pad your estimates to account for these inaccuracies. In the end, you'll have a good estimate to work from.
Let me also say I'm a realist. I know engineers cringe at the thought of documentation. However, my money says engineers dislike providing estimates they aren't confident in and missing their deadlines more than their disdain for documentation. When you can provide accurate estimates you gain a lot: confidence, trust, more normal business hours, and a rockstar rep.
