I’ve created a page called Software Development Mentor.
I’ve learnt a bit over the last 20-odd years of creating software and programming (ironically, something I originally never particularly wanted to do) and that’s the page where you will hopefully find a few nuggets of wisdom.
I actually have a couple hundred nuggets scribbled down so I’ll be updating the page when I have time or need a short break from creating a product and building a company.
Learning how code “hangs together” is crucial for all programmers. And it’s not that difficult.
Most software has an entry point, though it varies depending on the language or framework. Find and understand that entry point.
From there just follow the code. In procedural and object-oriented languages you’ll mainly be dealing with IF statements, SWITCH statements, calls to functions and calls to objects with properties and methods.
Watch what is called. Look at the parameters being passed into methods or class constructors.
Look at how variables are manipulated. Consider the scopes of variables and class properties – are the private to a function or class, or are the public? Are function parameters passed by value or by reference?
And think about namespaces – from the variables and functions that sit in the global namespace through to those nested under specific namespaces.
Functions will sometimes seem to be in a global namespace but are actually implicitly at a deeper namespace level thanks to using or include statements in the file (e.g. in C# and VB.NET).
PRO TIP: Make Find All (usually Ctrl+F) your best friend. If you come across a function or variable and don’t know where it’s defined or what it’s used for, any decent IDE with allow you to perform a “Find All” and list out all occurrences of it. Use that to trace the use of the variable/function.
But the most important thing you can do as a programmer is: take the time to read and understand the code. The more years of experience you have the easier and more intuitive it becomes, but always it is important. Learn how to follow the flows, intuit the structure and find where functionality lives.
This is the true heart of most programming activity.
I’m a very practical developer. My learning style has always been to learn how to do something, usually by example, now what it’s called.
As such, I know that I know how to write code with predicates, but I might still fail a multiple-choice test to describe what a predicate is.
So I looked it up again. And it’s really quite simple:
A predicate is a statement (or function) that returns either true or false.
You pass some data into the predicate. The predicate logic then performs a check on the data. Then the function/statement return a true or false result to the caller.
The 2 clearest resources with descriptions and examples I’ve found so far are this StackOverflow answer and this other StackOverflow answer (which is C# oriented).
A common example is a function or short comparison statement you write and pass into a function on a list that then performs a mapping or reduction on the list (e.g. to find a subset of items in the list that contain the value(s) your predicate function or statement is checking for).
For example, if I have a list or array of People objects and each object has an Age property, I can write a predicate …
(Person p) => (p.Age >= 18)
… that I pass into a select() function on the list to return only those people who are age 18 or older.
var australianDrinkingAgePeople = fullList.Select(Person p => p.Age >= 18);
In this case, it’s a shortcut for writing your own big for loops and if statements over the list (although there’s nothing to say that the select() statement doesn’t implement that logic behind the scenes).
These are my views and approaches on leading software development teams and managing people in general. They come from the culmination of a few years of on-and-off leadership, and a lifetime of observation (plus a share of suffering under poor regimes along the way).
In no particular order:
- Work for your team.
- Protect your team.
- Never pass problems down the line.
- Don’t talk about money with the team. They don’t need to know if the project is running over budget. They don’t even need to know the budget. That’s a management concern, not a worker’s concern.
(Definitely, don’t use budget issues as a motivator to make the team work more.)
- Push back on upper management if their requests and expectations are unreasonable.
- Give the team the tools they need to do their job.
- Don’t be cheap on tools and equipment. Supply computers with appropriate specifications, decent chairs, multiple monitors.
- Give the team the information they need to do their job.
- Give the team the support they need to do their job.
- Be patient.
- Don’t reprimand people. Be a “guide” for team members not performing to your standards.
- Be very clear about standards and KPIs if you’re going to hold people to them.
- If someone is not performing to a standard you expect, talk with them, work with them, help them be better. Raise the issue and talk to them early (don’t wait until the annual performance review).
- Leadership and management will mean tough, icky conversations. If you don’t have the stomach for that, don’t do the job. Skirting tough conversations is dangerous for the team and work outcomes.
- Don’t set estimates when you already have a deadline in mind. Just say the deadline and work with the team to figure out how to deliver.
- Don’t ask for estimates then hold people to it (Dr Evil style). It’s called an estimate for a reason.
- Software estimation is hard. Really hard. Really, very hard. Always remember that.
- Be clear about deadlines. And why the deadline was set.
- Realise that almost every single software delivery deadline set by business is arbitrary. And will slip. And people will burn out and get angry pushing to deliver for a deadline that slips anyway.
- Agile “story points” only work in true agile projects that don’t have time-based deadlines. Those projects are rarer than hen’s teeth.
- If you’re going to hold a team to story point velocity, you’re doing it wrong (and everyone better be very clear from day one what the real effort of a point is).
- You have smart, capable people in your team. Let them think and contribute.
- Team discussion is good, healthy, and expected.
- After the discussion, the decision at the end of the day is yours. That’s part of your responsibility.
- Don’t dictate to people. Direct and guide.
- Good leaders realise they have a team of smarter people or capable people, and enable the team to do good work. That’s the job of a leader – enabling.
- Don’t allow or make people feel guilty about mistakes.
- Understand the hurdles people face. Understand their problems. Understand the blockers.
- Understand what’s slowing people down. It’s not about working people like slaves but making sure the natural pace is not slowed down (e.g. by inadequate equipment, poor process, lack of understanding, stress bubbling from management).
- Don’t push people like slaves.
- People are people, not resources. Never call a person a resource.
- Praise goes to the team. Blame stops with leaders (never pass blame down to the team). A leader’s reward for a job well done is internal satisfaction.
- Software developers need time to breath, take a break, and refresh during the day. And during the week. And periodically over a long, hard project.
- Software coders should not be in front of their computer coding 8 hours per day. If they’re doing that then something is wrong.
- Working software developers hard for long periods will lead to burn-out and discontent.
- I don’t believe a rewards or hall-of-fame type system should exist for people who do extra work (hours) or produce extra stuff. That a) is the encouragement of overtime and, b) isolates the 90% of good people just getting their job done.
- Don’t ask for overtime. Ever. (Unless you can absolutely guarantee a time-off-in-lieu soon after the reason for overtime has passed). Overtime just means fuck-up somewhere up the management or sales chain that software developers are going to pay for by fixing it.
- Ask what people enjoy doing and want to do. What motivates people? What are their interests?
- Give people training.
- Give people support in career progression.
- Don’t presume you know everything as a leader/manager – you don’t. Don’t presume you have all the answers – you don’t. That’s not your job.
- Leaders don’t need to know everything. That’s why you have a team.
- A leader’s job is to have enough knowledge and experience to ask the right questions, trust their staff, do research and make good decisions.
- Draw the best knowledge, experience and ability out of people in the team.
- A leader needs to be “people” person. They need good social and communication skills. They need empathy and reflection. They need patience and a thick skin.
Managers also need at least some of this.
- Never assume a team member has a certain level of knowledge, especially in software languages, technology and tooling. For example, don’t assume everyone has the same level of Git knowledge (I recently made that mistake and had to correct it). Keep asking questions – basic questions – to understand everyone’s knowledge and comfort levels.
- Don’t talk “at” people.
- Don’t talk over people.
- Don’t micromanage your team, even those who are slow or make mistakes. Micromanaging is just a band-aid. If there’s a problem, work at finding and resolving the root cause – whether it’s a change of process, education or allowing someone time to learn and practice a new way of thinking and working.
Often a problem one person is having is a [silent] common problem across a team.
A soldier needs to learn to shoot a rifle on their own. Different soldiers need different paths to reach proficiency. A leader’s job is to help each person on their own path, so when the time comes to use the rifle each soldier can do it on their own without a leader on their shoulder telling them what to do.
- Keep processes simple.
Keep simple checklists.
Keep help easy to find.
Think like soldiers and pilots.
- Document. Document. Review. Document.
- Never stop thinking about how to improve processes, information, and team conditions.
- Never bring your ego.
- Don’t elevate a good senior technical person to a lead role that they’re not prepared for, wanting to do, or able to do.
I’ve seen too many good “senior developers” with poor people skills placed in a lead role that end up hurting teams (at worst the team and project becomes toxic).
Leave technical people in technical roles.
I was sitting at my computer typing status updates for my team when my wife walked into my office. So I looked at her, smiling, and kept typing to finish the sentence as she was reading what I was typing.
When I finished she looked at me and says: “you’re typing and not even looking.”
It was then I realised for the first time in a long time I have a rather useful skill: I can touch type.
In fact, I can touch type on both a conventional keyboard and, depending on the device/operating system, on a phone.
I may be wrong, but based on much observation of others, I believe that may now be a relatively rare and valuable skill.
But I can tell you one thing for sure: it’s a skill that’s taken many, many, many hours and years of practice to master.
Find the top people and organisations – the thinkers, leaders and “doers” – in areas of interest to you, and follow them.
Good people and organisations write regular blogs.
As bad as Twitter can be it’s a great place to find leaders in technology and software development. Twitter can also give you a closer to real-time flow of information and some good conversation to get you thinking.
Also, check if your favourite people are authors on Pluralsight.
And we have an ethical responsibility as software developers – and, for some, “hackers” – to consider the implications of what we create and do.
Users are people. Real people, like us, living real lives.
What we do has a real effect on people’s life. Now, and in the future.
Example: https://www.troyhunt.com/heres-what-ashley-madison-members-have/ and Troy has also noted some people have committed suicide over this breach.
If you were a software developer “just writing code” and created something that, how you feel if I:
- Collected all your data, collated it and create a “profile” of you to sell to others for the profit of others?
- Could learn so much about you it could create a “virtual you” that over an actor that could make you say and do things you never did?
- Allowed your identity to be stolen?
- Allowed your most personal information to be stolen?
How would you feel?
Well, all these scenarios have happened over the last couple of years, and all thanks to just 2 reasons:
- Developers who did not think about the implications of what they were asked to do;
- Vulnerabilities in the code they wrote.
I recommend adding these types of comments when writing code:
- Classes: A brief description of the class purpose.
- Functions/methods: A brief description of what the method does. It’s also good where possible to provide descriptions of the expected parameters and return value if applicable.
- Properties: A brief description of what the property is for.
- Most code has some logical grouping as it flows. Add a one or 2 line comment before each section describing what’s happening.
- If you write a complex piece of code/algorithm/fluent method chaining, add a description of what’s happening. Sometimes it’s difficult to determine what’s happening from the code alone.
Why is commenting code good?
- Put yourself in the does of someone who has to change the code later. Comments help other developers (and often yourself) understand what is happening, and what is supposed to happen.
- Comments are helpful in debugging errors, where the logic of the code may not match the expectations set out in the comment.
- Comments help other developers determine if a method or class is something they can use in their own code.