Mentoring Again

Background

A few years back, I was assigned an Apprentice to mentor. I said I would love to do it, but I questioned why the Senior Developers in the team didn’t have anyone to mentor when it is literally in their job descriptions.

At the time, my manager said that she thought I’d be the best mentor in the team, and if I do it successfully, then that is good evidence I can be promoted.

I think the mentoring went successfully, but I didn’t get a promotion.

Present Day

Fast-forward to the present day: My new manager said that an Apprentice is joining our team, and out of everyone, he reckons I would be the best mentor. If I do it successfully, then that is good evidence I can be promoted.

I said I’d love to do it. This time I didn’t complain about the Seniors not mentoring. I didn’t want to risk my manager reassigning the Apprentice. I have a good feeling my manager will actually promote me, but we will see.

The Future

I had a chat with my Apprentice. He has never done C# before; but it’s vital to our team. We already had a lack of developers – and a lack of skilled ones. Now we have someone who has never seen the program we are working on, and never used the language it is written in. He has come via a bootcamp that taught him basic Web Development, so that’s some wasted training.

This means that I’ll have to spend a lot of time training him, which means my productivity to bug fixes/enhancements will drop. Our team’s productivity was already low, and now we have another member which is actually going to decrease productivity. I hope managers realise this.

I think I’ll have to encourage him to learn as much as he can on his own. I’ve sent him a C# ebook which is pretty comprehensive. He has access to an online training platform to watch in his own time, plus all the rest of the free content on the internet.

This is another topic to write about on the blog. It can document me learning how to teach someone from scratch, and also document funny mistakes he makes.

O365 Integration

“Is it possible to get a few of us together to look at what areas of our software would be hit by Office 365? Another team is testing the integration and needs our assistance on the affected areas.”

Becky

In our software, we already integrate with Microsoft Word, but it relies on it being installed on that user’s computer. This request from Becky seemed like a random request, and there’s definitely a lot more information she needs to provide here.

So I asked “Have there been changes to our software to handle this? I don’t really get what this means. Instead of loading the locally-installed Word, is it going to launch a browser with Word in it? Does this include other aspects like Outlook, Excel etc”.

There’s loads of features of Office 365, do they want Outlook, Teams, Excel, Powerpoint or more to work? It simply isn’t going to work without us adding compatibility for it. Interacting with a Web Application (Word running inside a browser like Microsoft Edge) is completely different to interacting with a Desktop Application (Word running as a standalone software). The former will need to call an API/Web-Service, the latter is interacting with DLL files on the computer.

It turns out it was just the desktop Word application you can install via your O365 subscription. So it wasn’t really anything to do with O365 really. I found out because she eventually forwarded me an email. It had literally everything someone would need to answer her original question, it’s just that she didn’t bother sharing it

Additionally, the other team already had a list of affected areas, and what she really wanted to know if there were any other aspects they didn’t consider.

So why did she ask such a vague question, and why suggest we would be doing the analysis from scratch? 

What a waste of time. Absolutely infuriating. How many blogs am I writing about her poor communication?

Team Summary

The team is showing unwavering commitment, innovation, resilience, and drive to deliver continuously. I’ve never seen anything like it in the years I’ve been here.

Head of Development

I always say that managers often show a massive disconnect from reality. They seem to praise when the team has performed poorly, and I think this is another case of that. I went through our team’s changes in the last month. Merges are trivial and I don’t really count them as real work, but I’ve included them in the table anyway. 

Here is the analysis:

NameMergesFixesMy View
Me14I’ve been disappointed in my productivity. However, I haven’t done that bad when compared to everyone else. Additionally, I have got loads of changes in a branch, on hold; awaiting confirmation of actual requirements. 
Senior Dev111 (mainly small items)Decent work, but really only cherry picking “quick wins”
Colin4 (made a massive mess of one of these, made a bit of a mess with another. I think the other two were primarily to teach people how to merge [ironically].)5 (I believe 2 of these fixes were issues he created in the other 3)Colin wasted a lot of time by making a mess of a merge which introduced at least one bug, and he made a mess of one of his other changes. He claims he has been more productive whilst working at home.
Colin 203 (1 of which was removing an unused using statement)With only 2 real changes, one of which was small and it didn’t work properly; this is terrible performance.
Rob02Rob has been real quiet. I think he had a bit of time off work, but still, this is poor
Beavis01Beavis was primarily just making excuses why he can’t work. To be fair, there was one week where he was doing some other work for another team.
Total626
Our “drive to deliver

So in a month, we haven’t done much work. I’d be interested to calculate what the average amount of fixes developers do each month. It’s a bit meaningless because a fix could take an hour, and another fix could take a week. However, you would think it would average out over a period of time.

I’ve never seen anything like it. I might use that as a recurring phrase from now on.
My manager actually said to me that my efforts “haven’t gone unnoticed”. I didn’t bother to correct him. I think I need to play up the delusion to try and get a promotion. Honesty never got me anywhere before.

“I did not realise I had to check it in”

Beavis was assigned a fix for a release. We support multiple versions so it needed to go into the “Release” branch (older version) and the “Main” branch (current version). Personally I think it makes sense to make the changes into the Main branch, then merge them into the Release branch. It probably doesn’t make a big difference really, but I told him that.

Beavis decided to ignore me and just check in the fix into the Release branch.

A few days later, one of the Release Managers tells Beavis that his change is missing from the Main branch. 

“I did not realise I had to check it in”, he lies.

Beavis

The thing is, I then check the difference between Main and the Release branch and there’s two other check-ins from Colin and neither of them have checked it into Main.

I don’t understand how we have these developers that have worked here years and they still don’t understand our process.

The Code Analysis Meetings

Our Team Lead had been hyping up how important it is to improve the statistics of our codebase. So we have a report that runs and gives you metrics about duplicated code, “code smells”, possible bugs, test coverage etc.

Colin volunteered to lead on this. I know that he is just trying to impress our manager to try and worm his way into another undeserved promotion. The thing is, he isn’t even thinking about what he is doing.

There’s been 2 meetings per week, and it’s been going on for 3 months. I wanted to know what was going on because we haven’t heard any outcome from the meetings, and the statistics haven’t improved either.

Intervening

I asked one of the attendees if they had discussed a particular rule that was flagged by the report, and told him that if we suppress the rule, it will improve the metrics by 300 or so. He told me to come to the meetings.

So I join the meeting, and ask them to investigate the possibility of suppressing this rule and people seem to think it is a great idea. No one had any other new ideas, so then Colin said we would continue going through the report.

I asked him to explain the process since it was my first meeting. He said there are different severities like low, medium, high, critical, and managers only care about the two highest categories. So he was going through each rule and commenting on them saying they can be changed to Low, or that we need to fix them.

So we start looking at each rule violation, and there’s about 8 people on the call; mainly developers but a few interested testers, and 2 managers. I say “interested” because they have turned up to the call, but when Colin asks people to discuss it, no one can make a decision. Colin kept on trying to describe what the code was doing but made so many mistakes, I had to correct him several times.

I was basically taking over, but kept on asking for other people’s opinions, but people seemed pretty indifferent. The call had gone on for nearly an hour and a developer hadn’t said a word, so Colin accused him of being asleep. The developer said he was awake, but then continued to stay in silence for the rest of the call.

I was told there was another meeting in a few days time, and it would be more technical, so I agreed to join.

The Great Realisation

That meeting was basically the same people, but excluding the managers. Colin continued going through each rule violation again. The conversation that followed roughly went like this:

Me: “Hang on, this is taking forever. We are seeing the same type of rule violation and you have gone through about 15 of them now.”

Colin: “Yeah, there are loads”.

Me: “This seems like it is gonna take all year. How many violations of this particular rule are there?”

Colin: “4000”.

Me: “Hang on, let me get this right. You are going through each of the 4000 violations, analysing the code, and trying to decide if you should mark it as Low severity or not?”

Colin: “Yep”

Me: “Don’t you think it is stupid?”

Colin: “That’s what managers want us to do”

Me: “No, the managers want you to decide how important the rules are, not how important each particular violation is. If they were aware there’s 4000 of the same rule, I’m sure they wouldn’t want you to do this. Why don’t we just look at the rules? How many rules are there that are being flagged as High or Critical”

Colin: “5”

Me: “So you have had about 12 meetings to discuss 5 rules, and you haven’t even gone through 1?”

Colin: “Yeah”.

Absolute waste of time. Just think, if there’s only 6 people and you paid them £12 an hour, and had 24, 1 hour-long meetings that they attended – that’s a cost of £1,728. But then sometimes there would be more people attending, and you had the expensive managers too. What did they achieve until I came along? Nothing. No one questioned it.

The thing is, we are concentrating on the wrong thing. There’s plenty of bugs to fix which bring value to the users. Why are we wasting time tweaking things that don’t need to be changed? The crazy thing is, we are spending all this time talking about doing it, and it isn’t being done.

The Efficient Team

In the next meeting. I told the manager our new approach, and also raised some of my concerns with how much importance we are placing on this. She didn’t care about my concerns so that got ignored. What she did say was “you guys are becoming an efficient team”.

Is that even serious? Months of wasted time. The words sound sarcastic to me, but I think she was being serious; the tone sounded sincere.

So in conclusion: Colin was just trying to impress the managers by taking the lead, and so was everyone else really; they were on the call, but they really had no passion for what we were doing.

What happened to Project X?

A manager sends me a message asking if I knew if a “Project X Enhancement” project was still in development (where the original Project X was something I worked on a couple of years ago).

I told her I haven’t heard anything about this Enhancement project, but I did work on the original.

She then asks me if I could estimate how long the project would take.

I don’t even know what’s happening anymore. I was under the impression that her role was to basically manage project planning…

  • How does she not know if the project is still in development? 
  • How does she not know who was working on the project in the first place?

Surely she has enough experience to know that it’s impossible for someone to estimate a project when they literally know nothing about the requirements. Why would she trust my estimates? Surely it’s more beneficial to actually ask the people involved, and, if those people really are unaccounted for, then we’d better find them. Have we really lost contact with a team?

What is going on? How can we be in this situation?

Press F5 to launch

I had a look at my old team’s work to see what progress they have made and to reassure myself I had made the correct decision to leave that project. 

Not much has changed in months. All the issues we had haven’t been fixed. There’s errors logged to the console window, there’s loads of buttons that don’t work. There’s a few small features but nothing works properly. 

What made me laugh was a button that said “Press F5 to launch”. It’s a website. Pressing F5 isn’t going to launch a dialog; it’s going to refresh the page in the browser.

Maybe there is a way of overriding the browser’s refresh behaviour but that would be very annoying to the user.

What I don’t get is: how someone came up with that requirement in the first place, someone else implemented it and somehow didn’t realise it wasn’t going to work. Although surely they did realise when they wrote some code to do it, then pressed F5 and the page refreshes…but then checked it in anyway.

Honestly, you just can’t get the staff.

User has been deleted!

In previous blogs, I’ve told a few stories about how bad a software tester, Becky, is at communicating. Sometimes, it seems like she is trolling. Here is another story:

“My user has been deleted when I clicked the refresh button, how do I undo?”. 

Becky

Well, I think you should have panicked and logged a high priority bug if that was the case.

There’s obviously more to this than she is stating. Your user doesn’t mysteriously vanish by clicking a button which says something other than “Delete”. What makes her think she can undo this action? Why does she think this is normal?

I replied, asking her for more information: What was she trying to do? What does she remember clicking before it happened? 

Becky ignores my requests and directs her messages to a select few software testers.

What are the testers going to do? If there’s a serious bug, it needs to go to a developer to investigate, and promptly!

Why was she ignorant of my attempt to help? It made me think if she doubted what she was writing, and deep-down; she knew her user hadn’t been deleted afterall.

I decided to play around with the software and click some random buttons, but I noticed something peculiar pretty quickly. 

It turns out there was a bug in the displayed list of users. Her user existed, it just didn’t show it unless you selected a different filter button; then reselect the initial filter.

She didn’t bother logging a bug. It’s literally her job as a software tester.

Jon Skeet

Soon after I started using Stack Overflow to find answers to my programming questions, I noticed the same name answering the questions; Jon Skeet. His “reputation” was really high. So high, it was the highest on the site. 

His reputation has become so large though, that it has outstripped his ability, or so he says in his blog on Imposter Syndrome.  

I sometimes think that with other aspects of life. For example, can The Beatles be anywhere near as good as their reputation? Surely no band is that good. 

It’s funny that Jon even references his Chuck Norris style facts about his ability. The internet definitely see him as a programming legend of the C# world.

I think it’s undeniable that Jon Skeet is an expert. I think the best developers aren’t necessarily the ones with ability, but they also need the right attitude to compliment it. Jon’s support to the community by answering so many questions to aspiring developers on Stack Overflow – makes him an absolute legend. He deserves his reputation.

Shape Up

A bit of a rarity on this blog; time for something positive.

I have been reading the book “Shape Up” by Ryan Singer which can be downloaded free from https://basecamp.com/shapeup

Book Summary

Shape Up defines the Agile Process that Basecamp utilises. The summary at the end of the book lists their ideas as follows:

  1. Shaped versus unshaped work
  2. Setting appetites instead of estimates 
  3. Designing at the right level of abstraction 
  4. Concepting with breadboards and fat marker sketches (a sketch made with such broad strokes that adding detail is difficult or impossible)
  5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time 
  6. Choosing the right cycle length (six weeks) 
  7. A cool-down period between cycles 
  8. Breaking projects apart into scopes 
  9. Downhill versus uphill work and communicating about unknowns 
  10. Scope hammering to separate must-haves from nice-to-haves 

There’s quite a bit of Basecamp jargon in there. Some of the sections I didn’t care that much about, but there’s plenty of aspects that seem like they counter many of the problems I have witnessed when it comes to Agile development. So I think this book does provide answers.

Notes From The Book

Some key points that I liked or found interesting (this is basically me copy and pasting from the PDF):

  • Instead of a traditional two week sprint, they work in six weeks. This time is “long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start”.
  • They “focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?”
    • Small Batch : This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle. 
    • Big Batch : This project takes the same-size team a full six-weeks. 
  • They “give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time”.
  • “Pitches” are posted as Messages in Basecamp software. There are five parts to include in a pitch: 
    • 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this 
    • 2. Appetite — How much time we want to spend and how that constrains the solution 
    • 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand 
    • 4. Rabbit holes — Details about the solution worth calling out to avoid problems 
    • 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable 
  • “Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks or any pitches that somebody purposefully revived and lobbied for again.” 
  • Backlogs are big time wasters. “The time spent constantly reviewing, grooming and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now”. Pitches therefore, do not go on backlogs. “If we decide to bet on a pitch, it goes into the next cycle to build. If we don’t, we let it go. There’s nothing we need to track or hold on to. What if the pitch was great, but the time just wasn’t right? Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.”
  • “It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.”
  • The “Circuit Breaker”: “We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension. We intentionally create a risk that the project, as pitched, won’t happen. This sounds severe but it’s extremely helpful for everyone involved.”
    •  it eliminates the risk of runaway projects
    •  it means we did something wrong in the shaping
  • Dealing with bugs
    • Use cool-down – the two week gap between the six week cycles
    • Bring it to the betting table – plan it into the next cycle
    • Schedule a bug smash – dedicated time usually around downtime like Christmas

Personal Comments From My Experience

So some discussion on why their approach is good:

  • I found with 2 week sprints there’s a lot of meetings involved for only 10 days work. You end up spending half a day planning, then there are 1 hour meetings like the “Retrospective” that happen at the end of the 2 weeks. With all these meetings, it cuts into the 2 weeks. 6 weeks makes it seem like the planning is less frequent and more worthwhile. You have more to praise/criticise when you reflect on your team’s progress during the retrospective.
  • Sometimes important bugs become the priority then you end up shelving your work. It would be nice to have the intense focus to ensure you finish what you start.
  • When we get to the end of the sprint, it is too easy just to move the work into the next sprint, so it makes the 2 week block seem meaningless. Knowing the timing is stricter will put more focus on actually delivering.
  • Often, bugs that you think are annoying are deemed low priority so they get shoved on the backlog and never fixed. First of all, it would be good to have the freedom to fix bugs that personally annoy you. Secondly, what is the point of having a backlog if it’s just a list of work you know no one will ever address. 
    • “Is this bug logged?”
    • “yes, it was logged 3 years ago”.
    • “brilliant”.