Category: Opinion

Where are the recruiters who help their network “advance” a career? Or shift across disciplines?

No one stays in the same role forever. Especially in the tech sector.

I had to leave “employed” life to break free from being “just a programmer”, and still, I continue to get pinged for what I consider mid-level programming roles.
I’ve been programming for 20 years. I’m not interested. Was a recruiter ever going to ask what else I want to do?
(Well, sorry, too late. I’ve done it already, on my own. In the last 12 months I’ve now architected a business web-application platform, co-run a business and lead/manage/mentor overseas staff.)

If you’re a recruiter and want to stand out, help people move “up” or “sideways”, not just into the next dead-end, same-old-same-old job.

But then, that would require “cultivating” a network, getting to know people and staying in touch.

A stereotype is just a label we apply to something – more appropriately, someone – we see that fits a well-known set of attributes of that label.

“Stereotype” is no different to other words like “classification”, “categorisation” or “breed” (for cats and dogs).

The only different is stereotypes generally apply to humans.

Attributes of a person’s stereotype might include how a person presents and defines themselves (clothing, skin colour, skin adornment, hair, speech, presentation of wealth, etc.), where they live, what they do for work, interests, activities they undertake, and so on.

Come to think of it, don’t these attributes also apply to “demographics”?

So I wonder, are stereotypes any different to demographics?

 

The problem with stereotypes is we often take it to be [and use it as] a negative connotation.

But negativity is just an opinion.

We’re don’t complain about demographics.

And we generally don’t complain that the likes of Facebook apply these same attributes to people for ad targeting?

Yet we don’t want to be stereotyped?

We are a fickle species.

Where are the recruiters who help their network “advance” a career? Or shift across disciplines?

No one stays in the same role forever. Especially in the tech sector.

I had to leave “employed” life to break free from being “just a programmer”, and still, I continue to get pinged for what I consider mid-level programming roles.
I’ve been programming for 20 years. I’m not interested. Was a recruiter ever going to ask what else I want to do?
(Well, sorry, too late. I’ve done it already, on my own. In the last 12 months I’ve now architected a business web-application platform, co-run a business and lead/manage/mentor overseas staff.)

If you’re a recruiter and want to stand out, help people move “up” or “sideways”, not just into the next dead-end, same-old-same-old job.

But then, that would require “cultivating” a network, getting to know people and staying in touch.

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.
• Listen.
• 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.

Finally:

• 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.

A tip for junior and student software developers:

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:

1. Developers who did not think about the implications of what they were asked to do;
2. Vulnerabilities in the code they wrote.

No, they don’t.

Twice today I heard this exact phrase or a comment equaling it:

users do stupid things.

One instance was in relation to registering scores for the CrossFit Open. The second time relating to storing passwords on Post-It Notes.

Sure, it’s easy to say the person was stupid. They should have read the instructions. They should have understood the rules. They should know better.

But let’s understand 2 things:

1. Every single one of us is guilty of being a “stupid user”.
2. People simply take the easiest path to completing a task. It’s not their fault the path is wrong or insecure according to someone else’s standards – they just want to complete their task and get on with the day.

So no, I don’t believe there is such a thing as a stupid user.

In every instance, it’s a case of a poorly constructed interface or system, bad policy, or lack of good tooling that allows poor users to select the wrong easy path to completion.

Looking over some developer blogs of Pluralsight authors I was seeing their course titles and I realised something:

When a course has “advanced” in the title does that usually mean the subject matter is more complicated than it should be?

For example, “Advanced Dependency Injection”. Surely Dependency Injection is something we want to keep simple (though to be fair I argue everything should be kept as simple as possible)?
Can’t we just wire it up then get on with the real job at hand? What make’s it so complex there must be an “advanced” component?

It leads me to wonder why we even need a sliding scale of “easy” to “advanced” topics in software development?
What causes such complexity in a subject?
Is the topic truly large and complex?
Or are we, the developers, so lazy in our approach to implementation – or teaching – that we over complicate it (almost certainly unintentionally)?

We are now entering the age where anyone who was born in the last 10 years will be looking at the possibility of having their entire life recorded online for all to scrutinise, the good and the bad, without their choice, and they will never be able to undo that fact.

Why? Because parents chose to post the life of their children for the world to see. Because friends can record any moment they want and share as they choose.

And what goes online stays online, always available for someone to find.

We now live in an age of pervasive recording, where anything we do and say may be captured by anyone with a smartphone and shared for the world to see.

Privacy is dead. Long live privacy.