David Eves

As a director you should be ahead of the curve on things like emergent technologies and new methodologies or tools. The business will be relying on you to some extent to lead them on the front of software engineering so it should be considered your responsibility to keep your learning and development up to date. As a leader, you will also be responsible for the development of your direct reports (and theirs, too!). To achieve this as effectively as possible, you need to know what training and tools are out there that your reports need to learn. The world of software development can be punishing if you let your learning stagnate, so don't neglect this aspect.

Networking can be a dirty word when you consider career progression. There is a stigma that by leveraging your network to get ahead you are putting yourself ahead of more skilled peers who do not keep strong networks. The truth is that networking is a demonstration of soft skills that will prove vital when you transition from, say, a hands-on software role to a hands-off role where you will be managing stakeholders and providing strategic vision first and writing code a distant second. Having a strong network demonstrates that you can put yourself or your ideas forward and get people to accept them. This is vital for a director-level role and cannot be overlooked when you want to progress.

This isn't something a slapped-together spreadsheet can show you. You need quality metrics, like time spent on stories of equivalent complexity before and after the change; or number of issues raised in regression testing or in production, to show you the ROI on improving code quality. You also need to take a qualitative view by checking how quickly new developers train up on the codebase and how easily analysts/PMs can propose new changes. After a successful code review, you should see far less conflict between the technical and non-technical sides as developers will have a better view to what the requirements of change are.

A lot of data mining techniques revolve around mapping lots of small, disparate sets of things onto more refined, larger sets of things. The skill lies in knowing when to stop before you accidentally create nonsense. This will mostly depend on what task you are processing the text data for. Stemming will reduce words to a common root form that is not necessarily valid (e.g. 'mice' can become 'mic'), and lemmatization aims to find a linguistically valid root form ('mice' becomes 'mouse'). If you are creating, for example, an application that relies on correct use of language, you will want a lemmatization approach because you don't want it to receive nonsense input that will invariably produce nonsense output.

Be careful in your utilisation of tools for sharing/collaborating when the project is large in scale or there are a lot of stakeholders and developers. For example, if a stakeholder communicates a UI requirement on a Confluence page and the team handling UI development uses another platform or simply does not access this document then the requirement can be missed. This risk is amplified greatly when you have many stakeholders and several development teams across one programme or project. Therefore it is important to have controls in place to mitigate the risk of losing things in different communication channels.

Your github account is what many recruiters or hiring managers will look at to judge your aptitude. Make sure anything you have public is polished and high quality. Unfortunately if you prefer not to do projects in your spare time, this puts you at a disadvantage over candidates that do. Consider doing something small in your area of speciality to demonstrate your ability.