Full life cycle software developer
Have you heard of a full stack software developer? That’s a developer that can go from the front end user interface to the back end database.
Well, I consider myself a full life cycle software developer. That is what I would consider a person that can take an idea and turn it into deployed software.
I am a software developer that can:
- understand a problem
- come up with an idea to address the problem
- create requirements to implement the idea
- write epics and user stories to break the requirements down for implementation
- implement the solution end to end
- continue to learn to do more
I care about the business and can bridge it to the tech
With the number of hats that I have worn, I am highly effective in many roles. I don’t consider myself to be the best in many traditional role, but I can bring considerations for topics that those typically in the role cannot.
I can perform product owner centric tasks while understanding if the database design can support the product goals.
I can perform scrum master centric tasks connecting the front end, back end, and product requirements while considering the happy and alternate paths for testing.
I can write the code to make it happen!
My super power
My super power is my ability to turn a paper napkin of an idea into a implementation… Or supporting the whole team doing the implementation.
Above I make a deliberate distinction that I identify as a software developer, opposed to a software engineer (though I often do that role as well). I believe, software developers can tap a “less technical” side than software engineers. Why does that matter and how can that be a super power?
In my opinion, a product is only as good as the person translating the product vision into product requirements. This often falls to those who are not always knowledgeable in technology, data, and software development.
As a software developer, with a unique collection of additional skills, I believe that I have much to contribute when it comes to turning a product vision into to a product implementation.
If you would like to the see the paper napkin of an idea that I turned into an implementation, take a peek at my product idea InfoSecretary
Qualities I appreciate in code
Readability
Between code that is concise, fast, or readable, I gravitate towards readable code.
It is easier to make readable code fast than it is to change hard to read code.
Consistency
I enjoy consistency in terminology, code structure, and naming conventions.
It is easier to get things done when the code follows a pattern. That leaves the focus on what matters.
Scenario based Unit Tests
I have seen unit tests that simply verify that code paths are exercised. They suck.
Unit tests should be an embodiment of the requirements and use cases. Maintaining formal requirements is a lost art so this is the next best thing.
Reduced responsibility
Code that address multiple logic and technology concerns are complicated.
Code should address a single responsibility, where appropriate, so it is obvious what the code’s core concerns are.