I came across this excellent article recently and while the target audience is Software Architects, in my view this is a great book list for anyone who is looking to grow their software engineering skills in general. I often talk to software engineers about reading books as part of their professional development plan (I’ll over this is in a post soon).
What I really like about this list is that it is actually planned with an approach of building on previous books. So you don’t have to follow this exact list, but what you might think about is the importance/value of having a planned set of books/references to build upon rather than just have a random set of books to read.“
I particularly like the approach of introducing the DDD books later in the path.The foundational aspects of the initial books sets up DDD really well.
Awesome video on the Career Progression in Software Engineering : https://www.youtube.com/watch?v=yIPbE7BssOs
Structure of a PDP
I have to be honest. I try to follow the KISS (Keep it Simple Stupid) policy and for creating a PDP for a developer/software engineer that is so important. Also, it’s important that the PDP is just a one page document stored usually as a Word Doc, Google Doc etc…
The PDP has 4 parts/sections:
- Career Goal/Aim
- Short Term Actions
- Medium Term Actions
- Long Term Actions
A one line statement on where the engineer wants to be in 3 years time
Short Term Actions
Specific short tasks that can be completed in the next month. Examples include:
- Pluralsight/BUILD video’s
- listen to podcasts
- Read a book or a few chapters of a book
- Work on a home/hobby/sample project
- Work on an open source project
Medium Term Actions
Longer term projects or events that can be completed in the next 6-12 months. Examples include:
- Events ( DDD, NDC, Microsoft Ignite, BUILD etc…)
- listen to podcasts
- AWS/MS Exams (on path to Certification)
- Nano Degree’s or equivalents
Long Term Actions
Long term major achievements. Examples include:
- Tertiary Study
- AWS/MS Certification
Maintaining the PDP
I manage a large number of developers at work. In fact to explain things a little, here is my current BIO:
“Dominic is the Tech Group Lead in Xero. He’s been .Net developer for a few years now, and spends most of his time these days herding cats. In other words : he is responsible for the management, delivery and quality for a group of 25 devs, QAs and other techies.
He lives in the Paris of the South (Canberra) but doesn’t speak french. He’s passionate about Boardgames, Cheese and Wine”
One of the main tools I have been using managing developers is the use of a Professional Development Plan.
This series of posts will focus on what a PDP Looks like, how to create one and how to use them.
If you are totally unaware of what a PDP is have a look at a few articles:
Next, Part 2 the structure of a PDP