Categories
development

Career advice for graduates

I saw this tweet and I’ve been asked this question myself a couple of times so I wanted to highlight this as a reference for others, and collect my thoughts into one place.

Know what you want. E.g. Do you want a startup with scrappy hours but more influence or a big company with more structure but where you have less control?

You don’t have to have a public profile.

If you do have a public profile, make sure it reflects you well.

Doesn’t have to be a blog, but always be thinking about teaching others what you’re currently learning. It really helps you in appraisals, interviews and networking because you’re already reflecting on your skills, and you can more easily help others

Apply even if you don’t meet all the criteria. In most companies “must haves” aren’t. You’ll need to meet some, and be prepared to learn others, but don’t wait until you’re 90% ready.

Advertisement
Categories
development programming

Things I don’t know as of 2021

Things I don’t know

Last time round, I stated the things I didn’t know. Whilst the technical list hasn’t changed much, there’s a new set of skills I want to talk about for this year, as these are the things I want to know.

How to build a diverse team

I’ve worked in plenty of diverse teams, and I’m proud that we managed to build a team from all male to 50% female in the 2 years I was at my last job, but there was a lot of unique features about that job that makes it harder to replicate elsewhere. And some of the groundwork was laid before I joined.

How to be a good mentor

I started mentoring via coding coach last year, and I’ve had to tune my approach to each individual, but I’m still not sure the best questions to ask, and what’s the best structure. If I find out, I’ll share it here.

How to get a sleep routine

Sleep is important. But between the existential crisis of a global pandemic, with the subsequent upheaval of work processes, and the constant desire to get more done, I don’t always timebox what needs to be done, and things fall, including my blog, and my fitness. I have thoughts on how to prioritise and plan better, but I can’t control for external factors.

How to work remotely

Whilst I’ve been used to sort periods of working from home and working with teams spread across multiple offices, this COVID lockdown is different.

I’ve learned how to work asynchronously, but there’s no good replacement for the serendipity of a chat grabbing a coffee or over lunch. Whilst I’m cautious about returning, even when we can, I definitely look forward to seeing people in the flesh again. Even if we’re wearing masks.

Is there a better way to work?

Whilst trying to find how to work “like this, but over video”, I’ve started looking at how properly remote-first companies do it, reading DHH and Reinventing Work, and thinking if there’s a better way of organising work completely. Asynchronous, pull-driven, self-organised. How do open-source and open-contribution (e.g. Wikipedia) work, and are there lessons we can learn there to make companies more effective, more value-driven and more scalable?

Categories
development

Not being qualified as a graduate

I’ve seen some chat recently that cis white men tend to be overconfident in their abilities, whereas everyone else is under-confident, so those men get higher salaries, faster promotions and apply for jobs that others wouldn’t. I agree, but I also wonder how much of the impact is down to a nepotism that favours “culture fit” (such a horrible term), and how much is due to megalomaniac outliers (think any famous Silicon Valley founder) that have so much confidence they pull others into their wake.

I don’t doubt that I’ve benefited from privilege on either count, but as both ideas are equally alien to me, I am still contemplating which foundation needs crumble to correct the imbalance.

I’ve interviewed some of the overconfident. I didn’t hire them because they couldn’t demonstrate ability to match their ego, and couldn’t fit in any team. I’ve interviewed the under-confident too, and their abilities outshone their ego. I was happy to champion them when others were unsure and my decision was validated by results.

I’ve interviewed enough people to know this is an issue, but as someone who had imposter syndrome well into my first 2 jobs, I thought it might help others to hear about my start, although I accept I will have had far fewer negative encounters as I was learning the trade by virtue of how I look and sound.

The most important person in this story is now my wife. I’d definitely recommend have a champion on your side. Someone who will push you when you have doubts. Whether it’s a friend, a family member, a mentor or a recruitment agent you can trust. Someone who will encourage you to apply for that job when you only meet 30% of the criteria, who will challenge you to be your best, and point out your flaws so you can work on them.

Graduation

Looking for jobs after university was a depressing experience. The y2k surge had passed, the .com boom was bust. I sent off CVs to what seemed like every company hiring tech staff in Scotland (I spoke to IBM and Microsoft but they only had sales jobs). I had a few interviews but every company I interviewed for announced redundancies within 6 months. One guy in my class was offered a job, and flown to the US for training, and the job was taken away whilst he was in the air, before his contract officially started.

It was a rubbish time for jobs, unless I wanted to follow my classmates to London : jobs in banks with a 70-hour week, paying far less per hour than Scotland, and with higher living costs.

I was demoralized, and starting to wonder if I’d chosen the right career. It didn’t help that the “job board” on the AI lab only had one “poster”, for a burger flipper at McDonald’s.

Another option

My wife was studying for a PhD, and found an opportunity for me at Glasgow Uni. It was something I had thought about, but I hadn’t realized there was money available to study for one. It was in audio interfaces, which allowed me to combine my love of programming with a love of music, and I picked up a lot of new skills along the way : MFC; Win32; Matlab; C++; parsing to write my own DSL; data science – feature detection, non-relational temporal data.

A PhD is hard work, so major respect to anyone else who’s achieved one. It’s not for everyone but I thoroughly enjoyed the experience. It was definitely not was I was looking for when I was job hunting, but having someone throwing left field ideas at me helped me both to understand what I wanted, and to widen my horizon of opportunities to apply for.

Don’t be fooled into thinking “a tech job” is a software developer at a multi-national tech company. Be a tester, and architect, work in operations, or security, or User Experience, work in academia or government.

Categories
development leadership

CodeCraftConf 2018 : Successfully Growing A Team

Thanks to everyone who came to my CodeCraftConf session today, and to the organisers for all their hard work. Here’s the questions I asked, and I’ll follow up with my thoughts from the discussion.

Successfully Growing A Team

  1. When is it time to grow your team?
  2. How do you deal with resistance from existing team members?
  3. Is it more important to find a culture fit or build a diverse team?
  4. What is your biggest worry with your current team size, or with growing your current team?
  5. How frequently can you add new people to your team?
  6. How long does it take to integrate someone new?
  7. What practices do you use to ensure sustainable growth?
  8. How do you know when a team is too big?
  9. How do you split a team that’s grown too big?
  10. How do you grow a team when the existing members are already overworked?
  11. How long is your recruitment pipeline in terms of short-term planning (getting people in the door) and long-term planning (having the right team in place for next year or 5 years?
  12. How do you recruit outside your specialty?
Categories
development leadership

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

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.

Categories
development

Who do you work with?

In every company, and in larger companies, every department and location, there are key players who make the company work. They might be the boss who sets a clear vision, they might be the admin who goes above and beyond, they might be social butterfly who knows everyone. Whoever they are, they are the ones that keep the team working. And when any of them leaves, the dynamic of the team changes. Not always for the worst, but there is always a period of adjustment.

Sometimes however, several of them leave in quick succession, like canaries at the coalface. Or maybe they just stop doing what makes them effective, new directives from above, too busy on chargeable time, or something else. Suddenly the team starts jarring, and you don’t necessarily know why, because you haven’t seen what they’ve been doing behind the scenes. But if you feel that tide, you’ll know everyones getting their CVs ready, either to jump up or to jump out.

If you don’t know who your canaries are, keep a lookout, because apart from the leadership team, there’s likely a few you haven’t noticed. Who is really pulling the strings? Who goes above and beyond? Who seems to turn up in unexpected places? Who is the person people turn to when things go wrong or they need advice? Don’t go looking for the people who surround themselves in lights, who have a Heart of Gold and want you to know it. Look for those who are looking out for people who are invisible. Who is kind to the cats?

But equally, be wary of the teams where the canaries don’t get a chance to be found because something else gets in the way. The teams heavily populated by graduates, or men, beyond the industry norms. If toxicity is bred into the culture, the fatal warnings are much harder to spot. Toxic culture shields egos and protects the status quo, weeding out dissent even when that dissent is essential for the survival of the team.

Know who you are working with.

Categories
development

Ddd.scot, diversity, and your career

I had a great day at DDD Scotland, thanks to everyone who came along for the discussions. Apart from the panel sessions I chaired and participated in, Joe Wright ran a great mob programming session, Gary Fleming led a lean coffee session, and we had a couple of great lightning talks about recruitment at Skyscanner and Becoming a Technical Lead From Tugberk Ugurlu of Redgrave.

There were a few recurring themes that I want to highlight.

Diversity

This was a strong recurrent theme throughout the sessions in the community room. Whilst the focus was on gender due mostly to the makeup of the attendees, a few people pointed out the need to respect diversity for LGBT, age (graduates don’t have 5 years experience), family circumstances (single parents and others don’t have time in the evenings to do coding interviews), dyslexia and autism. To which I’d also add physical disabilities, skin colour, religion, any of which can and have been used intentionally or otherwise to limit the pool of candidates brought to interview, or created a hostile environment once in the job.

If you want to hire on merit, don’t just give the job to the white guy because he’s “a culture fit” and recognise that your recruitment may be biased. When I put an ad on Stackoverflow, all the replies were men, but working with a couple of recruiters we found a better mix of candidates, including the woman who we ended up hiring.

Job hunting and moving on in your career

There was a scary graph that suggests that computer scientists are less employable that other graduates, and yet of all the STEM subjects, there are more vacancies in software (where the stem jobs are ).

The job market is broken. There’s a lot of smart people out there, and for my last 2 jobs I had no experience in one of the key technologies they were advertising for, so the job adverts in many ways are meaningless. I want to work with people who have the skills to evaluate the next JavaScript framework, not 10 years experience in Vue. Nothing I work on today existed when I graduated. No ASP.NET MVC, no REST, JavaScript was for image rollovers, no Swift, no Xamarin. But job adverts don’t care about ability to learn. They’re a checklist.

I know recruitment agents get a bad reputation, and for some it’s well deserved, but a good one will help you get past the keyword gate, because they can sell you on your potential. If a company isn’t interested in your potential, choose another one. If you don’t want to deal with an agent, you need to be bold, demonstrate what you can for the requirements, and find examples to help them see that you can learn the rest quickly.

But have examples. You don’t want to be the clueless braggard who can’t even FizzBuzz.

Culture of learning, and mentorship

If you want to continue to be successful, you need to learn. Some of it you can do on your own, some you’ll need help with. If you’re working for the right company, they’ll provide you with a mentor, but even if they do, it’s worth finding others to help, whether it’s a formal process, or just someone to discuss if all companies make you deal with that stressful thing that’s getting you down.

Write a blog, volunteer for projects outside your comfort zone that help you improve those skills you’re lacking. Seek feedback. Accept that you won’t know everything and the learning experience is littered with failures. Learn by doing. Pair, mob, spike ideas.

When you’re tired of learning, find a new job.

Categories
development

New Job : Welcome to Screenmedia

Following my request across my network looking for a new job, I started at Screenmedia 3 weeks ago. For those who don’t know, it’s a digital design practice, which means I’m back to consulting, and I get to work with a lot of smart people, covering technology and design. I’m a Technical Architect in the integrations team, so that’s APIs, voice assistants, serverless, analytics, so should be a good wee adventure. I’ve got a few thoughts on the job hunt which I’m sure will come up at ddd.scot and future blog posts. But if you’re currently looking, we’re hiring. If you’ve got any burning career questions, the DDD Scotland panel survey is still open.

I’ve been working on lots of interesting projects already, so groking multiple domains, sometimes multiple for the same customer, Checking the checklists, and reviewing the onboarding process. Sometimes the best change is the one that lets you re-evaluate what you think you know.

 

 

Categories
development

Ddd.scot panel sessions and lightening talks

I’ve been selected for 2 sessions at DDD Scotland this year. There’s no presentation from me, but I’ll be chairing a panel, and appearing on another, so plenty of opportunities to answer questions. This is a new thing for ddd.scot, as well as the lightening talks stream to help you practice public speaking, or just share something cool. Please come along and provide your feedback.

If you’re coming, please submit a question to the Your Career in Software Development panel so we can answer the questions you have on your career. Submit your question anonymously here

Hope to see you there.

Categories
code leadership

CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
    • Pre-mortem
    • Chaos monkey
    • Agile “threw away risk register and other important documents”
  3. What makes a great team?
    • People
    • Feel comfortable
    • Trust
    • Communication
    • Balance
    • Good Leader
    • Sustainable development
    • Transparency
    • Healthy Debate
    • Growth and change
    • Common Goals
    • Motivation tailored to each person
    • Rules
      • Raise concerns
      • Feedback should be timely and structured
      • Coding standards
      • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
  4. What would you change about your current team?
    • Management
      • Decisions made outside the team, not taking input from the team
      • Coaching developers to talk to management
      • Wrong person promoted to lead
    • Too many rules
      • “Because we’ve always done that”
      • Needs the context of why that rule exists
    • Clear roles
    • Respect for decisions the team has made
    • No secret tasks
    • Co-located, or remote, not mixed.
    • No “them and us”
      • Manager vs developer
      • Techie vs non-techie
  5. What makes you feel unsafe in a team?
    • Lack of:
      • Support
      • Communication
      • Respect
      • Goals
    • Secret genius / hero developer who does their own thing
    • Decisions made without buy-in
    • Teams without source control
    • No tests
    • Secrets
    • Success at the expense of others
    • Developers are not “resources”
      • And managers are not “overhead”
    • Fear
    • Stagnation
  6. How well would your current team survive a conflict?
    • To survive, have Strong Opinions, Weakly Held
    • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
    • Avoid imbalance in workloads that lead to loading stress onto key individuals
  7. Should teams change when projects change?
    • Teams should be mixed to avoid stagnation, but not completely break them up
    • Good teams can inspire others
    • Every good team cares about the product they produce
  8. How does the culture of a team change as it grows?
    • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
    • Lines of communication fail, especially as distance increases.
    • Old vs new – “I prefered the company when it was smaller”
    • T-shaped individuals are better collaborators
    • Tribe structures can help by allowing multiple communication lines
  9. What kinds of diversity should we seek in the teams we work in?
    • Diverse teams build diverse products
  10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
  11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub