Getting from a Jr. Software developer to Software developer Level 1 might have seemed like a long way to go but this is just the first step for a Software developer career in ApexSQL and all the future steps have even steeper learning and growth curve
If you've certified as a Level 1 dev then it means:
a) You've been working in a fully functional team the company can rely on
b) Have been a leader at least for a specific task or a goal within the team to carry your own weight
c) Have gained enough experience with how we work and have already mentored other colleagues or can do so now
d) You've grown and developed your hard skills just enough so that for any new challenges you encounter you already know how to approach resolving them even when it requires more learning
e) You are successfully saving time to stakeholders and are working with them vs. working for them or thinking there is us-and-them
Time period
How long will it take to get from the day 1 in ApexSQL to a Software developer Level 2 will depend on each person individually - if you started as a Jr. Software developer (Level 0) then you'll need at least 3.5 to 4 years to be able to check off all of the items below
No regression
The first expectation is that you constantly confirm the level you're currently at which means you don't regress by no longer doing the work you were successfully doing before, or by doing it slower (i.e. you caught lazies)
If you had regression in your performance then it is critical to first make sure you get back on track and have consistent high performance of at least 3 or more months in a row - not doing so risks actual regression back to a Level 0
Soft skills + 1
When doing a Level 2 values review expectations will be one step higher than those for a Level 1 performance review
If you had a "Needs improvement" score for any of the values but have still managed to certify for Level 1 then those values if not improved in the meantime will read as "Unsatisfactory" during the Level 2 review which is a showstopper
If you had a "Meets expectations" score for a value then you need to have displayed consistent or improved values match in order to keep reading "Meets expectations" for the Level 2
Hard skills++;
Jr. Software developers can best testify the amount of new development knowledge and skills gained when going from Level 0 to Level 1 - the same goes for a Level 1 dev aiming to certify as Level 2
Each team has a bit different hard skills requirements depending on the owned product set so the only common metric here is how have those hard skills helped you be more efficient during work
Success = results / time;
The better hard skills you gained then you'll contribute to your team with more results over less time
Value added time saver
Can you confirm all of this:
1) Are you self-sufficient enough so that others don't need to "manage" you by asking questions and giving directions / frequently correct you
2) Do you communicate proactively and in an actionable manner with the stakeholders / no surprises caused by you and your team
3) Do you educate stakeholders and provide suggestions and guidance yourself
4) Can you be a role model for all Software developer Level 1 peers
Achievements
Additional information we should put on a table before starting the perf review for Level 2 is the list of achievements you can brag about since you've certified for Level 1
If you don't have anything exceptional to show for as a Level 1 dev then how can you justify you have earned the next level
This is also a great personal litmus test you can do for yourself before reaching out - are you able to provide a list of at least three achievements that you are proud of during your Level 1 tenure?
But don't say that i.e. you're proud of showing up for work every day or that you've managed to complete 3 sprints in a row as these are just normal everyday expectations so you won't be doing yourself a favor
For example:
a) Took initiative to build a component / engine / feature which helped the team by ...
b) Improved communication of the team with the stakeholders
c) Helped the team achieve PUQ superiority by fixing X bugs in Y time / by improving performance by x% / by identifying and fixing usability issues
d) Mentored new colleagues so that they have achieved ...
e) Suggested [and helped implement] a feature / functionality that directly helped with Platinum goal
f) Successfully managed X subcontracted projects
g) Worked with team SEs to ensure uninterrupted team content flow
h) Took ownership of a standard and helped everyone enforce it
Also such achievements are good to have but aren't the ones we're looking for:
a) Learned to write thread safe code like a boss - good for you
b) Read 3 books on design patterns - congrats
c) Went to a .NET conference - nice
d) Learned angular / js / css - great if it'll help you get the job done, but the focus is on the achievements that are "done" and have directly helped with your team and the company goals
Monday, October 31, 2016
The art of specs
In the initial The art of subcontracting article we've covered in short differences between functional/technical and requirements/specification
When preparing initial documents to describe a subcontracting project we have 4 distinct levels of documentation "depth" where each is more detailed than the previous one - and you don't necessarily need to document everything down to the lowest level in order to have a successful project
Level 1: User stories
User stories are a great way to abstract yourself from the technical minutia and to define top-level goals for the subcontracting project - they are the answers to "What?"
User story is a one-liner where you can describe your project goals to a person who is seeing the project for the first time and has no idea what you want to accomplish - never allow subcontractors to figure this out for themselves
Also a user story will make sure that the user (you) achieves clarity about the project goals before going down the rabbit hole
User story has a few elements:
a) "As a user" - this puts you in the proper set of shoes on start as you are the user
b) "of the <final deliverable>" - clarify what is the expected end deliverable of the project: an app, a component, an engine, documentation, specs, etc.
c) "I want to be able to <functional goal>" - one desired project use case
Some examples:
As a user of the application I want to be able to... (one goal what you want the application to cover, i.e. allow for browsing database encrypted objects, to be able to easily decrypt database objects)
As a user of the component I want to be able to... (visually view database objects in a form of a graph, manipulate database objects as a graph)
As a user of the engine I want to be able to... (access all of SQL Server instance properties in an object model form)
As a user of the functional specification I want to be able to... (have a detailed functional requirements breakdown for the engine mentioned above).
This specific user story is great for when creating specs-for-specs (see appendix)
As a user of the automated test I want to be able to...
All but the simplest projects will have more than one user story defined - i.e. one user story per needed application/engine feature
Level 2: Functional requirements breakdown
Once user stories are defined they can now be broken down into individual and more detailed functional requirements
Functional requirement is a free-form short description that further explains a user story
To breakdown a single user story "As a user of the visual component I want to be able to view database objects as a graph":
a) Each object type should be visually represented with a different geometrical shape
b) Related objects should be interconnected using lines
c) We should have several predefined presets / algorithms for object layouts
...
Functional requirements are short and don't go into details, i.e. what kind of geometrical shape should be applied to what type of object, how will object name be displayed, color of the shape, etc.
It is critical to invest as much time as needed to define all functional requirements that we need on start.
If we uncover that we've missed to define a functional requirement during the project then all such burden of additional requirements will fall down on us (as project appendixes that bear additional costs)
Level 3: Functional specification
Each of the individual functional requirements can be further broken down to create a functional specification / functional details
Consider each of the functional requirements as a new paragraph or a separate section with a freedom to go into all the tiny details
A section "Representing object types visually" can have:
a) A mockup / picture of a representative object type
b) List of default geometrical shapes, colors, text
c) List of configurable elements, and all required shapes to be available
...
Drawing up a good functional specification is very time-demanding and depending on the project scale and complexity it can be wise to consider subcontracting this work (see appendix)
Level 4: Technical specification
The lowest level of a subcontracting document is technical specs which can be more or less detailed, or can be skipped altogether
Almost every development subcontract will have some basic technical requirements in a form of required development technology, coding standards, etc.
Anything more than that is very risky as it effectively spoon-feeds the subcontractor and requires a lot of micromanagement time on your side thus making it questionable whether you should've worked on the project by yourself from the start
A good rule of thumb is to avoid technical specification whenever possible, or if really needed have subcontractors work on it prior to beginning any actual implementation/development work
For specific projects where it is important to go down to tech spec details level, try to keep it as short as possible
Appendix - Specs for specs
The main goal of subcontracting is to help you achieve team goals as quickly as possible (success = results / time)
Smart product teams will keep this in mind at all times and will not replace their development time with spec writing time
A smart product team will spin off subcontracting projects by focusing on writing up Level 1 (user stories) and Level 2 (functional requirements) subcontracting documentation
As such you can have subcontractors write Level 3 and Level 4 (functional and technical specification) documents themselves which you can later review and approve prior to starting the implementation
a) Know thy comps - research and figure out in details who we want to better / what we want to achieve
b) Know thy goals - write up good user stories by yourself what we want to achieve (Level 1)
c) Know thy needs - write up all functional requirements (Level 2)
d) Make it so - have subcontractors do the remaining work by writing the remainder of the project documentation prior to implementation
When preparing initial documents to describe a subcontracting project we have 4 distinct levels of documentation "depth" where each is more detailed than the previous one - and you don't necessarily need to document everything down to the lowest level in order to have a successful project
Level 1: User stories
User stories are a great way to abstract yourself from the technical minutia and to define top-level goals for the subcontracting project - they are the answers to "What?"
User story is a one-liner where you can describe your project goals to a person who is seeing the project for the first time and has no idea what you want to accomplish - never allow subcontractors to figure this out for themselves
Also a user story will make sure that the user (you) achieves clarity about the project goals before going down the rabbit hole
User story has a few elements:
a) "As a user" - this puts you in the proper set of shoes on start as you are the user
b) "of the <final deliverable>" - clarify what is the expected end deliverable of the project: an app, a component, an engine, documentation, specs, etc.
c) "I want to be able to <functional goal>" - one desired project use case
Some examples:
As a user of the application I want to be able to... (one goal what you want the application to cover, i.e. allow for browsing database encrypted objects, to be able to easily decrypt database objects)
As a user of the component I want to be able to... (visually view database objects in a form of a graph, manipulate database objects as a graph)
As a user of the engine I want to be able to... (access all of SQL Server instance properties in an object model form)
As a user of the functional specification I want to be able to... (have a detailed functional requirements breakdown for the engine mentioned above).
This specific user story is great for when creating specs-for-specs (see appendix)
As a user of the automated test I want to be able to...
All but the simplest projects will have more than one user story defined - i.e. one user story per needed application/engine feature
Level 2: Functional requirements breakdown
Once user stories are defined they can now be broken down into individual and more detailed functional requirements
Functional requirement is a free-form short description that further explains a user story
To breakdown a single user story "As a user of the visual component I want to be able to view database objects as a graph":
a) Each object type should be visually represented with a different geometrical shape
b) Related objects should be interconnected using lines
c) We should have several predefined presets / algorithms for object layouts
...
Functional requirements are short and don't go into details, i.e. what kind of geometrical shape should be applied to what type of object, how will object name be displayed, color of the shape, etc.
It is critical to invest as much time as needed to define all functional requirements that we need on start.
If we uncover that we've missed to define a functional requirement during the project then all such burden of additional requirements will fall down on us (as project appendixes that bear additional costs)
Level 3: Functional specification
Each of the individual functional requirements can be further broken down to create a functional specification / functional details
Consider each of the functional requirements as a new paragraph or a separate section with a freedom to go into all the tiny details
A section "Representing object types visually" can have:
a) A mockup / picture of a representative object type
b) List of default geometrical shapes, colors, text
c) List of configurable elements, and all required shapes to be available
...
Drawing up a good functional specification is very time-demanding and depending on the project scale and complexity it can be wise to consider subcontracting this work (see appendix)
Level 4: Technical specification
The lowest level of a subcontracting document is technical specs which can be more or less detailed, or can be skipped altogether
Almost every development subcontract will have some basic technical requirements in a form of required development technology, coding standards, etc.
Anything more than that is very risky as it effectively spoon-feeds the subcontractor and requires a lot of micromanagement time on your side thus making it questionable whether you should've worked on the project by yourself from the start
A good rule of thumb is to avoid technical specification whenever possible, or if really needed have subcontractors work on it prior to beginning any actual implementation/development work
For specific projects where it is important to go down to tech spec details level, try to keep it as short as possible
Appendix - Specs for specs
The main goal of subcontracting is to help you achieve team goals as quickly as possible (success = results / time)
Smart product teams will keep this in mind at all times and will not replace their development time with spec writing time
A smart product team will spin off subcontracting projects by focusing on writing up Level 1 (user stories) and Level 2 (functional requirements) subcontracting documentation
As such you can have subcontractors write Level 3 and Level 4 (functional and technical specification) documents themselves which you can later review and approve prior to starting the implementation
a) Know thy comps - research and figure out in details who we want to better / what we want to achieve
b) Know thy goals - write up good user stories by yourself what we want to achieve (Level 1)
c) Know thy needs - write up all functional requirements (Level 2)
d) Make it so - have subcontractors do the remaining work by writing the remainder of the project documentation prior to implementation
Friday, October 14, 2016
Jr. Software developer trial period breakdown
Trial period length
Jr. Software developers have the longest trial period when compared to all other roles at ApexSQL
Many of the guys who start at this entry level position have no previous work experience or at least no experience in software development jobs, and have a limited hard skills set
Improving hard skills and earning experience is only possible through actual work by developing products and taking part in ideally every step of the product new version life cycle covering the concept, analysis, roadmap, design, development, testing, release, and agile support
ApexSQL is made of guys who are dedicated and see themselves in the IT battle trenches for years to come by sharing both success and failure with the rest of the company
How long it will be until you complete the trial period it'll mostly depend directly of you, and of your team, but specifically trial period for Jr. devs with no previous experience is usually 9-12 months and depends on your growth curve, team achievements, and individual results
Specific requirements
0) To even start talking about successful end-of-trial it is mandatory for all our devs to read in full and to share on the subject of The Inmates Are Running the Asylum book.
This step is also a prerequisite for any software design and usability improvement discussions / tasks
1) The first step of each performance review is that the team (a product team consists of both devs and Support engineers) must have a good standing and good results at least for the past 3 months.
This comes down to successful ownership of team products by:
a) Having good team transparency: no surprises for stakeholders; share proactively - raise suggestions vs. asking questions or providing one-sided decisions
b) Don't expect to be told what to do and don't allow to be asked what you're doing - if someone asks for an update then it is already too late
c) Ideally have a few product releases under your belt - not all teams have this but it is a good achievement to have if applicable
d) Uninterrupted new content flow - this part is owned by team SEs but if they get stuck it will come down to devs in the team to help out even though we'd like to avoid this as devs should focus on development work
2) The second step of the perf review is to have good individual results that speak for you and to actually own some team goals.
One option is to became a go-to guy in the team for a specific area, to directly contribute to your team through learning and sharing about a specific area, subcontract management, QA and test automation, development/implementation of a specific engine or technology, or something else.
This doesn't mean to isolate other team members from an area of code or to work alone in isolation as that should never happen, but instead take ownership of a goal within the team and with the help and collaboration from the team you complete it from start to finish
And most importantly share regularly about your team and individual achievements and progress - don't expect someone will be spying on you or monitoring your every step; no one will notice if you don't share for yourself
Also don't hide behind other team members - there's no such thing as a team lead in ApexSQL or a team PR
Owning a goal means you won't wait on everything to be reviewed by everyone else in the team and to reach a "consensus" - help is welcome and collaboration is good, but you should never wait on anything or anyone and should take full responsibility for the goals you own
3) The third step is values review from peers, mentors, colleagues, stakeholders - just read our Working Naked values statement and let me know if you have any questions
4) The final match-80%-of-job-level-requirements step is not required for a successful end of trial for devs as certifying for Software developer Level 1 requires even more battlefield experience and hard skills which can be ideally achieved in the next 6-12 months at most
Benefits
Upon successful end-of-trial performance review Jr. Software developers remain Jr. devs (Level 0) but gain paid vacation time proportionally for the given year, and are paid during the month for the ongoing month (vs. at the end of month)
Later on when you finally certify for a Software developer Level 1 it comes with commensurate increase in salary, and depending on the current company policy also covered local contractor monthly taxes and insurances
On the right track
Ask yourself:
A) Is my team proactive enough, do we get many questions from stakeholders or we're able to anticipate questions by regular sharing of our status, plans, and recommendations
B) Are we sprinting regularly in the team, learning from our failed sprints, and doing everything we can in order to succeed each of the team sprints
C) Am I contributing in my team by sharing responsibilities with my colleagues without skipping out
D) Am I there for my team members when the going gets tough
E) Am I sharing regularly with the stakeholders for both my team and myself, or am I expecting that others in the team will be sharing for me
F) Are we (devs) helping our team SEs with customer support and with content. How is my team SE doing right now
G) How much did our team and I contribute to the company when compared to other Jr. Software developer teams / individual devs
H) Am I repeating mistakes or am I learning each day so that my next day is always better than the previous one
What next
Reach out to HR and/or Facilitators whenever you have any doubts or when you lack feedback
Otherwise we'll keep an eye out and touch base when we consider you ready for a potentially positive first performance review
Jr. Software developers have the longest trial period when compared to all other roles at ApexSQL
Many of the guys who start at this entry level position have no previous work experience or at least no experience in software development jobs, and have a limited hard skills set
Improving hard skills and earning experience is only possible through actual work by developing products and taking part in ideally every step of the product new version life cycle covering the concept, analysis, roadmap, design, development, testing, release, and agile support
ApexSQL is made of guys who are dedicated and see themselves in the IT battle trenches for years to come by sharing both success and failure with the rest of the company
How long it will be until you complete the trial period it'll mostly depend directly of you, and of your team, but specifically trial period for Jr. devs with no previous experience is usually 9-12 months and depends on your growth curve, team achievements, and individual results
Specific requirements
0) To even start talking about successful end-of-trial it is mandatory for all our devs to read in full and to share on the subject of The Inmates Are Running the Asylum book.
This step is also a prerequisite for any software design and usability improvement discussions / tasks
1) The first step of each performance review is that the team (a product team consists of both devs and Support engineers) must have a good standing and good results at least for the past 3 months.
This comes down to successful ownership of team products by:
a) Having good team transparency: no surprises for stakeholders; share proactively - raise suggestions vs. asking questions or providing one-sided decisions
b) Don't expect to be told what to do and don't allow to be asked what you're doing - if someone asks for an update then it is already too late
c) Ideally have a few product releases under your belt - not all teams have this but it is a good achievement to have if applicable
d) Uninterrupted new content flow - this part is owned by team SEs but if they get stuck it will come down to devs in the team to help out even though we'd like to avoid this as devs should focus on development work
2) The second step of the perf review is to have good individual results that speak for you and to actually own some team goals.
One option is to became a go-to guy in the team for a specific area, to directly contribute to your team through learning and sharing about a specific area, subcontract management, QA and test automation, development/implementation of a specific engine or technology, or something else.
This doesn't mean to isolate other team members from an area of code or to work alone in isolation as that should never happen, but instead take ownership of a goal within the team and with the help and collaboration from the team you complete it from start to finish
And most importantly share regularly about your team and individual achievements and progress - don't expect someone will be spying on you or monitoring your every step; no one will notice if you don't share for yourself
Also don't hide behind other team members - there's no such thing as a team lead in ApexSQL or a team PR
Owning a goal means you won't wait on everything to be reviewed by everyone else in the team and to reach a "consensus" - help is welcome and collaboration is good, but you should never wait on anything or anyone and should take full responsibility for the goals you own
3) The third step is values review from peers, mentors, colleagues, stakeholders - just read our Working Naked values statement and let me know if you have any questions
4) The final match-80%-of-job-level-requirements step is not required for a successful end of trial for devs as certifying for Software developer Level 1 requires even more battlefield experience and hard skills which can be ideally achieved in the next 6-12 months at most
Benefits
Upon successful end-of-trial performance review Jr. Software developers remain Jr. devs (Level 0) but gain paid vacation time proportionally for the given year, and are paid during the month for the ongoing month (vs. at the end of month)
Later on when you finally certify for a Software developer Level 1 it comes with commensurate increase in salary, and depending on the current company policy also covered local contractor monthly taxes and insurances
On the right track
Ask yourself:
A) Is my team proactive enough, do we get many questions from stakeholders or we're able to anticipate questions by regular sharing of our status, plans, and recommendations
B) Are we sprinting regularly in the team, learning from our failed sprints, and doing everything we can in order to succeed each of the team sprints
C) Am I contributing in my team by sharing responsibilities with my colleagues without skipping out
D) Am I there for my team members when the going gets tough
E) Am I sharing regularly with the stakeholders for both my team and myself, or am I expecting that others in the team will be sharing for me
F) Are we (devs) helping our team SEs with customer support and with content. How is my team SE doing right now
G) How much did our team and I contribute to the company when compared to other Jr. Software developer teams / individual devs
H) Am I repeating mistakes or am I learning each day so that my next day is always better than the previous one
What next
Reach out to HR and/or Facilitators whenever you have any doubts or when you lack feedback
Otherwise we'll keep an eye out and touch base when we consider you ready for a potentially positive first performance review
Subscribe to:
Posts (Atom)