Ask Your Mentor These 40 Questions : success (Q11-20)

Lifehacker suggests 40 questions to ask your mentor. So that I don’t have to repeat myself, I’m posting the answers here in 4 chunks.

11. What decision netted you the most success in your career?

I quit my job. I was unhappy but I didn’t realise it at the time. I had nowhere to go but no-one was being highest with me. So I looked. For about 2 years. I tried to change my role in the company, or look for a promotion, but no-one was ever clear about what the gap was from where I was to the next step up. So I quit, helped build a fantastic team, and saw a great uptick in my salary.

12. Is there a particularly effective strategy for achieving success in this field?

Have broad knowledge. T-shaped, if you like that term. Know enough to understand and explain technical problems to your peers, even if you leave design, architecture and implementation to others. Know what their constraints are because it will make your job a lot easier. More than anything, hone your bullshit meter, because everyone you meet is biased, and chances are a few will be liars and charlatans.

13. Which people do I need to stick around to maximize chances of success in this field?

Anyone outside your group. Find a technical architect or a marketing person you can learn from. Find people who will broaden your horizons.

14. Where should I be networking?

In the TCP stack.

For connecting with people all bets are off in this pandemic, but connect with people the same way you would outside work – find common interests, maybe technical, maybe a hobby. Find people that you have the knowledge or connections to help.

15. Have you ever made a single change that led to tremendous success?

I stopped trying to keep up with every new framework and language. I’m happy to be a leader in different ways.

16. How can I be more strategic in pursuing my career goals?

Know what you want. Do you want t to be a domain expert? Do you want to be an architect? Do you want to lead and mentor? What will make you excited to get up for work.

Pursue that.

17. What traits do I need to exhibit to stay ahead of the curve in this industry?

Understand how to solve problems and the limits of computers. Read Turing.

Understand people. They’re the ones you need to communicate with. Your job is to be an interpreter.

18. At how fast a clip can one reasonably expect to climb the ladder in this field?

It’s faster in a start-up, with a lot more breadth. It’s more structured and supported, but slower, in a bigger company. Which suits you better?

19. What should success look like at this stage in my career?

Are you interested in your work? Are you learning something new?

20. What should I be focused on right now to smoothly transition into the next leg of my career?

Understand the business. Debug how the processes really work and who has the keys to your next job.

View on Trello

Ask Your Mentor These 40 Questions : failure (Q1-10)

Lifehacker suggests 40 questions to ask your mentor. So that I don’t have to repeat myself, I’m posting the answers here in 4 chunks.

1. What’s a big mistake you’ve made that you’d want others to avoid repeating?

Never take responsibility away from a team. Empower them and trust them. If you lead a team, don’t tell them that the buck stops with you, tell them that the buck stops with all of them. You can defend the team from others, and take responsibility for failures externally, but always make sure everyone is accountable for their own work and you all succeed together or not at all.

2. What’s your strategy for overcoming failure?

Move on. Leave the failure in your notebook, or in your action log. Own the failure, understand why it happened and work to avoid that situation in future. Put safeguards in place, rework the environment, but don’t expect future you not to fall into the same trap as current you. Move the trap where you will notice it.

3. What’s an essential lesson you learned as a result of failure?

An untested backup is a wish, not a promise. Test it to make sure its a promise.

4. When should I give up on a pursuit?

When it no longer provides value. Or there is a better way to provide the intended value.

5. Do you believe in the sunk-cost fallacy?

Absolutely. And I have worked on projects that recognised this, restarted from scratch, and delivered for less than the change in estimate to continue the project.

6. How do you assess what feedback is legitimate?

It’s specific, The person giving it has your trust, or the trust of others you respect, It’s given in kindness even if it’s given with force.

7. How do you integrate feedback into your work and lifestyle?

Always listen. Ask for feedback. But most importantly, act on the feedback, and show yourself acting on feedback, because that always encourages more. If feedback is lost, new feedback is never given, because what’s the point?

8. How big of a risk is too big of a risk?

Depends on the project. A team of 1 can handle a much bigger risk than a team of 100. A team with a strong PM who manages risk well, can handle more risk than one with a weak PM.

9. How do you determine which weaknesses can be overcome?

Ask. Whichever weakness you have, someone out there is thriving with it.

10. Can you tell a story of how you recovered from a massive blunder?

[I deleted a database]

Sometimes the greatest challenge of leadership is making your boss understand what you do all day

Everyone loves a maverick. The one who bends the rules, who gets the job done. Who leaves fireworks in his wake (it’s always a man) and doesn’t mind breaking a few chickens to make an omelette. The people who rescue the projects in a tailspin, who shout loud and carry a big stick.

What happens to the projects without fireworks? The sysadmins that don’t have to explain why they got breached? The project managers who don’t have to explain why they went over budget? The developers who aren’t in the office past midnight fixing bugs? The people who aren’t visible because they fix the problems before they become visible?

I grew up watching Formula 1 with my dad, in the era of Senna and Mansell. Senna was fiery, pushed the car to the limits, exciting to watch. Mansell was controlled, steady, hitting the right line, and easing the car in as if it was on rails. Senna looked like the hardest worker, but Mansell broke his run of world championships.

If you’re competent, if you get the job done, then people believe that your job must be easy. It’s not easy to beat a triple world champion. Sometimes you need to anchor your achievements in advance, so people understand the challenge in hindsight, especially if you are marginalized in the workforce such that your achievements are minimised.

The Difficulty Anchor

Hey underrepresented folks in technical roles! Performance review season is upon us. I want to take a few moments to remind you about some practical tips that can help you be evaluated more fairly in this and future seasons.

— Mekka 💉x7 @mekkaokereke (@mekkaokerekebye) August 9, 2018

It’s even harder once you move into any management role, success is due to your team (and be damn proud of that success), but failure falls squarely on your shoulders. If you don’t have a strong sense of your own self worth, it can hollow you out, and leave you with nothing but a thick skin.

Take on extra responsibilities, be the consistency for the team when the powers above you are a maelstrom of confusion and musical chairs. And nothing happens.

Remove obstacles and no-one sees them.

Anchor your team’s success. Quiet, dependable successes make everyone on the team happy : no drama, no overtime. But it can be hard to show the work behind the scenes that makes it look so smooth.

It’s not just a dev problem, a good sys admin is invisible, designers struggle to prove their worth (How to Prove Your Design’s Value – Hack Design
https://hackdesign.org/lessons/57-how-to-prove-your-design-s-value?utm_source=newsletter&utm_medium=email&utm_campaign=howtoproveyourdesignsvalue ).

Market yourself. I know you hate sales and marketing, you’re happy to leave it to others, but you need to give yourself the confidence to be proud of your achievements and make sure people understand what you did. Share it with your boss and your peers (you’ll need some recognition when it comes to your appraisal). Promoting yourself is not someone else’s job. Practice it. Embrace it. Be proud.

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

Naughtonomy

Wherever the wind takes you

If you want a strong team of developers, give them autonomy. But what if they don’t want to take it? The ones in, or from, the big corporations who just won’t take the initiative? The ones who just want to be told what to do?

I’ve said before that those are the waterfall people. The cogs in the machine.

Have you been a developer who didn’t want to take responsibility for yourself or your work? Who doesn’t have pride in your work, and just wants the money? Do you want the opposite of autonomy?

It might not be your fault. If you live in a blame culture, you want to leave as small a footprint as possible. Head down, do as you’re told. Don’t attempt that risky refactoring or upgrade. After all, if you do it, and it breaks, it’s your bonus that gets lost, and your neck on the line for big failures. If you don’t touch it, and it breaks, maybe the previous touchee will get passed the grenade, or maybe it will just get blamed on a faceless, incomplete “process”.

Maybe your manager doesn’t want you making decisions. You’re not important enough. You don’t have the power to make them. Developer ideas don’t matter, listen to the manager, or the architect.

Or maybe you want to be motivated, to get autonomy and change things.

Show your boss this. Or get a new job.

Event Horizon : When sharpening the code means missing bug zero.

A great programmer sees software as a craft, honing a perfect solution from a sea of binary logic. Good software is beautiful outside and in, and even on a large scale is simple enough that there are no obvious bugs. They produce software that is precise and clean down to the last detail, continually improving quality. 

But it’s easy to fall into the trap where quality beats everything. The software cannot ship until every bug is fixed, every scenario is covered, even the heat death of the universe. And the software still hasn’t left your machine.

Until your code is in front of your users it’s an untested hypothesis about what they want and what they can use. And hypotheses, no matter how precise, have a habit of not surviving contact with reality.

Test early, test often 

So start with a smaller hypothesis. Remember that for most of what we do, Newton’s laws of motion are good enough, and simple enough. Unless you’re building something that depends on very precise timings and/or very high speeds, you don’t need to handle relativity.

So ship it.

Build it. Test it. Ship it.

Prove your hypothesis meets the real world, and use it. Define your MVP. Cut it to the bone. And ship it.

Make sure you’re building the right thing: ship it.

Bug Zero 

Every project has a bug zero: no-one can use something that doesn’t exist, and isn’t live.

Fix that bug first, because every other bug depends on it. Either the bug is important enough for them to complain and tell you want they want. Or it’s never used, so remove the functionality.

 

Fear of failure, and risk-takers

We all make mistakes. We should learn from them, whether it’s because we didn’t know enough, or because we’re taking a risk. People are afraid of mistakes. We’re afraid of being found out. We need to fight imposter syndrome, and tell the world we are not phonies. So we don’t want to fail, we don’t to make mistakes, so we avoid taking risks.

But what if, when we ask Is it OK to fail? we start asking instead, “is it OK to learn?” or “Is it OK to to take risks?” If you feel like an imposter, that you’re out of your depth, you have 2 options:

1. Decide you need to learn. I’m currently in charge of a team that’s moving to a more devops culture, and I don’t know enough to know if we’re doing it right. So I’m reading, and testing, and building out my knowledge, so that I can make some mistakes and learn from them, to help me understand the mistakes bigger teams made so I can learn from them too.
2. Decide you don’t need to learn. Trust your team, or a 3rd party to deal with it for you. Learn how to detect bullshit, and let them deal with the detail.

I loved reading Risk taking and imposter syndrome at Google where Google talk about battling imposter syndrome head-on. When you are surrounded by the brightest and best, you are always going to struggle with confidence. So ask everyone what risks they are taking, and what they’re learning. What do you know today that you didn’t at the last stand-up?

When you are adding value, no-one will think you’re an imposter. And hopefully, neither will you, but when you do, know you’re not alone.

Go learn.

 

 

Your API sucks : notice period

Based on a true story, although as one of the clients in question, I can’t guarantee the validity of the conversation. Any similarity to any developer alive or dead is purely coincidental.

“Dave, we need to make a change to our API.”

“Is it a zero-day security issue?”

“Nah, but it’s pretty important.”

“Will it break existing clients?”

“Yeah, probably, we used to recommend 128-bit keys, and we need to jump to 512-bit keys.”

“Do you think we should tell our users?”

“Yeah, probably. Want to let marketing know?”

“Shall we tell them it’s important?”

“Nah, they’ll figure it out.”

2 weeks pass

“Hey, support  have started getting a lot of calls about clients who cannot connect to our API, any idea why?”

“Erm….”

“Did we make a change and not tell our users?”

“Erm….”

“Do you think we should tell them?”

“Do we have to?”

Remember, even if you do give a positive notice period, your clients will need lead time to update their code.

The importance of language: company culture

There’s language you use in a team that defines the project. The language that a company uses defines every project. Get it right and the company makes people happy. Get it wrong and your staff, and your customers, will start asking what’s wrong, and you might not be able to tell them.

Don’t be creative

Software development is just a matter of sitting in front of a keyboard and typing. Thinking isn’t software development. Designing isn’t software development. Talking isn’t software development. Even if it’s talking to a duck. Therefore, in order not to disturb those who are working, get away from your desk and go be creative somewhere else, you anti-social malcontent.

Or maybe lateral thinking and problem solving are exactly what you’re paying software developers to do. Just because you don’t understand the beauty of what’s being produced, doesn’t mean the beauty isn’t there. I understand developers need quiet time, but most developers (and any developer I’d want to work with) need to be social. Sometimes you talk through a problem, sometimes you debate alternatives, and sometimes you chat over a coffee to take your mind off the problem for long enough to be able to find the solution.

Just one little thing 

Software development is easy. Sure, there’s hard problems, but that’s what those other guys in Microsoft, and Google, and Apple do, not us. So those requirements we asked for an hour ago, should be done by now, right? After all, it was just one change to our database to support transgender employees.

OK, so I didn’t realise we didn’t have Mx as a title, but that’s just one other little change, right? No, I don’t know what a boolean is, or what that’s got to do with the gender column, but you can just add one more value, can’t you? I don’t know whether all the historical records need to be changed, I’m not a developer, can you just add support for transgender or not?

Just is a very dangerous word.

Right first time

We’re a company that our users can trust. We don’t make mistakes. We do it right, first time, every time. And anyone who doesn’t can go work for someone else. Losers.

Or, we’re a company that doesn’t take risks. We’re scared to fail and we don’t know how to recover from failures. If we make one mistake, our house of cards will fall and our users will leave. We don’t innovate, we can’t adapt. And if we fail, we’ll blame someone else. We’ll brag about our self importance to cover up our tiny exposure, and we’ll come down like a ton of bricks on anyone who questions us.

Don’t be that company. Sometimes things fail. Expect failures, expect things to go wrong. Figure out how to recover. A customer who has a complaint dealt with quickly is often a happier customer, and a better ambassador, than a customer who hasn’t, or can’t complain. Don’t make mistakes for the sake of it, but take risks, be interesting, and learn to right yourself when you capsize.

Take your laptop home

The modern workplace demands flexibility. Sometimes to accommodate work, because international companies need to work to international timezones. Sometimes to accommodate life. Don’t discount good staff because they have childcare duties, or other demands on their non-work time. 9 to 5 isn’t the only way, so long as people do the work and are involved in the right conversations.

As a worker though, that flexibility in hours means that sometimes you need to work after bedtime, or you need to learn about a new technology in an evening or weekend event. You don’t stop thinking when you leave the office, but you can stop taking every call.

The modern workplace is noisy. It’s full of distractions. Go home and disconnect so you can have the peace you need to get in the zone. But put it in your calendar, in advance, so no one is surprised.

But only take what you need. Prepare your equipment and your space. Make it productive.