What Makes An Effective Developer?

Last Monday and Wednesday Bob Breznak, lead developer at Everture, visited Startup Institute and taught the students in the web development track about scoping and building projects.

Here are some of the ideas about how to tackle a development project that Bob shared during his visit.

What will get me the furthest today?

Before getting started take a step back. Think about the core tenants of why you’re doing something.

What are the goals?
How things are going to get built will shift but the goals don’t change as often. Think about and solidify the goals behind your project. What’s the deadline? How is the application expected to work? What should the experience be like for the user?

Break down goals into targets
Goals are useless if they’re not turned into actionable items. Always consider if the implementation is testable. Small actionable tasks are great for morale - and you actually get stuff done!

INVEST principle created by Bill Wake covers the characteristics of a good-quality user story.

Independent - User story should be self contained in such a way that there is no inherent dependency on another user story.

Negotiable - Can always be changed and rewritten.

Valuable - Must deliver value to the end user.

Estimable - Be able to estimate the size of a user story.

Sized appropriately or small - Should not be so big that it becomes impossible to plan/task/prioritize with a certain level of certainty.

Testable - Must provide the necessary information to make test development possible.

Build
Identifying goals and having a collection of actionable tasks will help you get to the point where you can start building. However, building doesn’t mean taking it upon yourself to create everything from scratch. Use other people’s stuff. If it doesn’t add direct value to the company, don’t waste time building it in house. Try to get away with writing no code and reuse whatever you can. You should always ask yourself, “Does this task help us accomplish our goals?” If not, reduce it and scrap it.

REUSE - REDUCE - RECYCLE
Write it in such a way that you can throw it up on GitHub and use it later. Release it!

“Be a disloyal developer”
When working with open source code, use it until you find something better. It’s important to figure out which tools are out there that can best help you do your job. Don’t be married to a tool because it solves a problem once. If you learn or come across something that improves upon the previous tool, burn the bridge, and integrate the new one. Most of the time, a tool kit won’t solve your exact problem and you will have limitations. However, finding a tool that solves most of your problem is better than building it from scratch.

Yak Shaving is the last step in a series of steps that occurs when you find something you need to do. “I want to wax the car today.”

"Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot."

"But Home Depot is on the other side of the Tappan Zee Bridge, and getting there without my EZPass is miserable because of the tolls."

"But wait! I could borrow my neighbor’s EZPass…"

"Bob won’t lend me his EZPass until I return the Moshi pillow my son borrowed, though."

"And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it."

And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.

The point? Super-efficient hackers learn when to say “no” to the temptation of endless fiddling.

Technical debt

Martin Fowler describes technical debt as having a piece of functionality that you need to add to your system but there’s two ways of doing it. One is quick to do but is messy - you are sure that it will make additional changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Doing things quick and dirty sets us up for technical debt. Developers may incur technical debt to hit an important deadline. We have real world constraints that we’re working up against. Be conscious of the consequences related to your development decisions and take on technical debt only when it makes sense.

Its been an incredible first few weeks at Startup Institute. The pace of learning has been fierce and we are all growing as people. My experiences as a student in the web development track will be covered in later posts.