How high can you jump?
The answer doesn’t really matter – the whole question is theoretical in any case.
The real question is – when your boss tells you to jump what initial thrust is needed and at what angle to achieve the desired flight path while sailing through the air.
It might also just be the case that your boss doesn’t even want you to jump at all.
Sit down. This isn’t about leaping about all nimbly-bimbly here and there.
What this is about is a discussion about professional development as a software developer.
The jumping metaphor is a great way to describe a transition for any developer from a fresh-faced newbie to a more seasoned next level developer.
You know, one of those people that now has just enough information to be dangerous?
Let’s take a step back and not jump to any conclusions yet.
See what I did there?
Thing about someone just starting out in the world of software development. If you are fresh out of school or haven’t had a fulltime job in this field yet then this could be you.
For everyone else, this was you at some point in your career.
We all went through this phase.
When someone asked you to do something, what did you need to do it?
The jump metaphor probably needs to be expanded a little bit here. Let’s consider a video game instead that has a run, walk, jump, and climb mechanic for the main character.
As an entry level developer, you are tasked with doing something.
This is no different than in our fictional video game world being tasked with getting from where you are now (point A) to that high ledge (point Z) over there.
Now in this game, it just so happens that you have to program in each step along the way.
Literally.
Now as a junior dev you know the basics of programming. You can probably even manage to make your character walk without any external help. But getting to that specific high ledge is tough.
So between your manager, product owner, and other more senior developers they help you out and put some more requirements and guidelines in place.
Walk from point A to point B. Easy, you can handle that.
Climb ladder C to first ledge D. Wait – you didn’t realize that there was a ladder there did you?
Walk to edge of ledge D and jump to ledge E. However, this jump requires a knowledge of the game physics engine and the calculation of an angle off the platform that will provide enough force and momentum to get you over and up in the game world to that next platform.
Then you just keep going, getting help along the way for all of the obstacles until you end up happily at point Z and you are done.
Now on to the next task.
After a while at this you start getting good at it. You learn. You grow.
Maybe there is a cost to jumping vs using a ladder. You get more efficient in your movements and your coding.
During this time you start finding little ways to optimize your path from point A to point Z.
This is you learning and growing.
Good job!
So time passes. As others recognize your growth the tasks provided to you will start to change.
Instead of the now simple and trivial task of going from point A to point Z at some point your task will be different.
Now you just get a task to complete the level.
Uh-oh.
This is different. You are now on your own to complete something. This is definitely not a task for a junior developer.
No – this is a task for a seasoned and experienced software developer!
So you jump into it.
Jump here, walk there, climb that.
Eventually you present your entire level walkthrough to others on the team.
At which point you come crashing back to earth because it is wrong. It is all wrong.
So where did this go off the rails?
Why were you so successful as a junior developer but your first few attempts at the larger picture are failing miserably?
Back in the video game level, others on the team point out a few things.
First, a requirement to grab the power up on a small ledge at the beginning of the level was missed.
Second, the customer wanted to see the underground that is only available if you took the second green pipe. Your pathing avoided that because it wasn’t the optimal route.
Third, you climbed up to grab the golden key as a bonus for the level. The requirements didn’t call for it. Now it turns out that nobody liked that and you ended up wasting a lot of time coding those moves and energy in getting up and down those ladders to collect that key.
Yes – you have fallen victim of one of the biggest pitfalls in development.
You have committed the mother of all screwups.
You made some bad assumptions.
Yes, assumptions are the mother of all screwups.
They will always come back to bite you no matter how experienced you are.
However, you have to build the skills of validating at least the big stuff in order to not fall into the lava pit of assuming.
As a junior dev people know that you won’t be able to question and validate those assumptions, so your tasks are much more defined and there is a lot more oversight.
As you gain experienced, not only do the tasks become broader in scope, you may find yourself writing the task in the first place.
Sure, you can get from point A to point Z, but are you hitting both the clear and explicit requirements as well as the unstated expectations? Are you validating each step of the journey? Are you delivering the right solutions?
In other words – how high are you jumping?
Never forget, that no matter where you are in your development career, that communication and validation of assumptions are critical skills to delivering the correct product and solution.
It doesn’t matter how new and inexperienced you are – the sooner that you start working on these skills the faster you will get better and gain valuable knowledge about development.
Also, when you do gain that experience, you cannot forget the lessons learned from your initial failures and you always must remember to check your assumptions.
Keep up the good work and keep coding.
Thanks for reading!
Comments are closed, but trackbacks and pingbacks are open.