Being part of a development team for an organization is a refreshing change coming from several years as a solo freelance developer. While I enjoy doing freelance development, there is something about being a part of a larger organization that helps motivate me in ways Freelancing did not but - being part of a larger development team, which is actually just a team as part of a larger organization - does come with it's own set of challenges I had to learn and absorb. And glad I did so, as I think in the long-run it makes for a better developer overall.
With so much fresh-blood pouring into the industry and with how rapid technology changes, of my ten plus years as a full-stack web developer this is something my mentors have drilled into my head over the years...
Don't focus only on the "How" - Stop thinking like a developer!
Early in my development "adventures" I was part of an 'upkeep and maintenance' team and was often called in to help the business solve a particular set of issues with currently running legacy systems.
For all issues I was assigned, the old me did a simple discovery (or scope) planning session, learned as much as we could and then happily powered up my editor (Eclipse at the time...) and started to hammer away at some ugly code solution.
For simple support tickets, this was fine and I was getting pretty good experience fixing CSS issues here, and simple Javascript interactions there until my first major project landed in my lap, a new feature to our slider - add full-screen video slides.
"Ok, great!" I thought as I assigned the ticket to myself and started to get cracking on how I was going to make a full-screen video player slide in and out, not stutter and then transition to the next video.
Two days worth of coding later, I update the ticket with my progress, show awesome screenshots and examples and promptly get chewed out by our Project Manager.
"What happened?!" I thought. "Where did I go wrong??"
I bulid what they asked for - or so I thought...
Focus on the "Who", "Why" and "What"
A lot of the time as a developer (myself included) we get caught up in the finer details of things and since we know how the inner-workings of the web it's easy to quickly deep-dive into 'how' we should go about solving a particular problem (and quickly end up knee-deep in prototype land with no scope) before realizing we forgot to ask some key project questions.
Who?
Being some of the most important questions, 'who' covers many topics/angles depending on the point of view.
In this case, I never asked the people in the business unit,
- 'Who' will update or add slides?
- 'Who' is picking the videos and from what source are they being delivered (Youtube, Vimeo, Self-hosted)?
- 'Who' is going to update already inserted slides and correct issues?
Why?
Helping to organize the bigger picture, 'why' covers many topics/angles depending on the point of view.
In this case, I never asked the people in the business unit,
- 'Why' self-host the videos over Youtube or Vimeo?
- 'Why' do we need to hide play buttons?
What?
Helping to tie loose strings, 'what' covers many topics/angles depending on the point of view.
In this case, I never asked the people in the business unit,
- 'What' is the expected behaviour of the slide?
- 'What' data does the CMS need to create a video in the template?
- 'What' starting list of video content do you have?
All of these items needed to be scoped out as part of the discovery process and I never did - I just dived right into the 'how' worrying about things like black-background flicker, maintaing proper aspect ratios on mobile and a custom mute feature.
The biggest take-away I got from that project was that my first step, my first several steps really - was never to start coding. I should never be coding right away on projects, always take the time to ask lots questions and learn more about the "big-picutre" of the project, business, goals - whatever.
'Who' is this for?
'Why' is this being done this way?
All of these important questions all help you formulate the 'how' - your specialization - and asking lots of questions helps make the 'how' that much easier on yourself.
Have a nightmare project that you'll never forget? What was it and what was the most important thing you learned for next time? I would love to hear your thoughts!
Top comments (0)