DEV Community: teachingtechleads

Learn About the Agile Methodology by Watching a Toddler Solve a Puzzle

teachingtechleads — Sat, 02 Nov 2019 02:08:11 +0000

Back when I was first cutting my teeth in the working world, Agile Methodology had just started being a buzzword. The manifesto was written in 2001 and our company was still chasing waterfalls, like TLC in the 90's. We started implementing SCRUM, poorly, sometime between 2010 and 2015. We were really trying, except doing it all wrong. Meetings were still scheduled to plan when we would plan for things. There was a deadline to march towards and we made the estimates work to fit that timeline.

It was awful.

Originally posted on TeachingTechLeads.com

My new company is a bit better at it. At least my team is, the rest of the floor and our upper management? Not so much. But, I finally found a way that made it all click for me.

I taught my toddler to solve a puzzle, using quick iterations and feedback loops.

Up Front Design in Puzzle Solving

I was sitting on the floor with my son, trying to lay out some basic patterns for how to solve a puzzle. This one was tough, he was zoned in on a hippo and had completely forgotten about the half finished monkey in the tree on the other side of the picture. He hadn't even found all the corner pieces yet!

I, of course, have been doing puzzle solving since the 80's. I know the ins and outs. I have a list…

Setup the puzzle box, so I can see the reference material - Requirements Gathering
Flip over all the pieces, so I can see what we're working with - Architectural Design
Separate the border pieces, so I can lay the groundwork - Context Design/Framework
Group the pieces by shared color/context, so I can create work divisions - Container Design
Build out from a corner, one grouping of pieces at a time, so I can complete the entire puzzle in one fell swoop - Implementation

Seems logical right? I can't know where I'm going until I know everything about how I'm going to get there and how I'm going to turn this one big pile of pieces into a masterpiece.

Agile Methodology in Puzzle Solving

That's not how my kid approaches it. He dumps the puzzle box over and dives in. This is the rough overview of his process:

Dump out the puzzle
This is a hippo, I'm going to put this hippo piece here
And this is a Tiger
But this is another HIPPO!
Good, the hippo is done, and it looks like it connects to something with long spotted legs, let's just see where this goes if I connect it to this other one
Oh man, I found a monkey, where does this monkey go? Another monkey! Awesome.
Dad said something about a giraffe, I guess that neck piece should go in between the body and the head, that makes sense.
THERE'S A PANDA!

We're putting together the same puzzle, but he's having way more fun. His approach resonates too, let's see if we can break it down.

Get it all out there, lay out the high level solution design.
Start working.
Did you finish a requirement? Cool, release and move on to something else.
When working on the next requirement, did you learn something about your previous requirement? Great, update it and re-release.
These two things pair well, we can connect one implementation to the next to fulfill the next requirement. Then release.
Hey, we got some feedback from the client that something doesn't look right. Great, we'll add it to the next release cycle. Thanks for the feedback.
THERE'S A PANDA!

Why My Toddler is Smarter Than Me

Subheading: Because he takes after his mother.

While my go to was the old waterfall style of starting only once I knew exactly the route I was going to take towards completion. And then once we start, we head forward and out in all directions, like Romans conquering everything in sight.

My kid, on the other hand, would knock out some low hanging fruit, and then move on to something else completely. Opposite side of the puzzle, who cares, this looks interesting for the moment and maybe it will connect with the other chunks I worked on at some later date. Whenever I offer a suggestion, he takes it in stride and applies it to things he may have made a mistake.
Mistakes are completely fine when you have a quick feedback loop and can correct them.

Key Takeaways

I think that's the biggest part of the Agile approach that has always hit home for me. Quit feedback loops, fast and frequent releases. Get the solution in the hands of the users and listen to whatever they have to say, often.
There are tons of other lessons we can learn from watching a toddler figure out a puzzle and a lot of them line up with the Principles in the Agile Manifesto. Like, I didn't think it'd be this close when I started writing this entry, but it's pretty spot on.

Early and continuous delivery of valuable software[puzzles]
Welcome more puzzle pieces
Deliver parts of the puzzle frequently
Cooperation between puzzle solvers
Trust those other puzzle solvers…
Especially when they're sitting right next to you
Pieces that fit together is the primary measure of progress
Sustainable development(maybe not this one, we take lots of breaks)
Not so much
Not so much
He reinforces his own patterns every time he does the puzzle
We sometimes talk about how we can connect pieces in a different order to see a different outcome

I mean, some of these are a stretch, but a lot of them are in line with the original Agile Manifesto. So, out of the mouths of babes?

Yes, Mr. Beck. You are in like minded company with my three year old. I think you'd get along swimmingly.

Callouts

Have you guys ever had a tech pattern or paradigm just click for you one day when you were doing something no where remotely related to it? I love seeing real world examples reflect things that I use in my development, like... solving puzzles.

What's the issue with the MockedProvider component?

teachingtechleads — Sat, 26 Oct 2019 17:15:25 +0000

Hey DEV community, I'm struggling with why the react-dom library is yelling at me in my tests. So much so, that I spun up a git repo in order to demonstrate what the issue is that I'm facing.

If you pull down the repo, you can see the console warning, even though I'm getting passing tests.

Quick overview of the test:

Wrap a component in a
Provide the MockedProvider with a mock query/response
Mount said component via enzyme
await the data to refresh and run my assertions

Every time that I run the tests, I get the following console warning, in bright red colors:

  Warning: An update to Query inside a test was not wrapped in act(...).

    When testing, code that causes React state updates should be wrapped into act(...):

    act(() => {
      /* fire events that update state */
    });
    /* assert on the output */

    This ensures that you're testing the behavior the user would see in the browser. Learn more at https://fb.me/react-wrap-tests-with-act
        in Query (at App.tsx:37)
        in div (at App.tsx:36)
        in App (at App.test.tsx:51)
        in ApolloProvider (created by MockedProvider)
        in MockedProvider (created by WrapperComponent)
        in WrapperComponent

I even followed the link and used the act() function referenced. I actually left that third test in there, because it throws the same warning.

So, is it that I'm using Enzyme to mount instead of React Test Renderer? Anybody have some tips? I'm open to pull requests with best practices for testing.

Finding your own work/life balance and why I choose to pay someone to clean my house

teachingtechleads — Wed, 23 Oct 2019 01:26:05 +0000

One of the biggest lessons that I needed to learn was how to maintain a life outside of the office. It's a tough one. Finding a work/life balance is an often scoffed at idea, especially within the IT community. When you hear about someone that doesn't work on side projects at home or doesn't have a side hustle in the industry, it seems a bit off.

"You just go home and don't code?"

Originally posted on TeachingTechLeads.com

I talked about this previously in my "What do you do again" article, but I burned out at my previous position after working 70-80 hour weeks for months straight. I didn't engage with my friends, or my partner, and I barely left my keyboard except to sleep. And it was the worst thing I could have done for my career and, more importantly, for myself.

Find Time for Work

I'm not saying you should flake on work. Quite the opposite, you should give all you can to work within the time constraints that you set. We used to refer to it as "leaving it all on the field" on my high school soccer team. You gave everything that you possibly could to affect the outcome of the game, and whether you won or loss, you accepted it and moved on after the final whistle.

The same should hold true in the office. Come prepared to work, stay off your social media during work hours. Complete your tasks and enrich the environment around you. And then?
Go home.

Find Time for Yourself

You're no use to anyone if you don't take care of yourself. This means physically, mentally, and emotionally. There's a lot that goes into making you a complete person.
Research shows that physical well being leads to better cognitive functionality. What this boils down to is… if your body is working at 100% then your brain will follow suit. Besides, working out has other fringe benefits.
To anchor this point, I'll share what I am up to nowadays. I try to get in two yoga sessions a week, mainly in our spare room with a youtube channel playing on my tablet. I play in a social soccer league every Tuesday night.
And I chase my toddler around whenever I have the chance. Cardio, baby.

Find Time for Others

That last point leads directly into this one. You need to leave time for a social life.
I play soccer with a bunch of random people who quickly became my go-to friends for calling up on a weekend to grab a beer. It was a huge step to take, as a social introvert, but signing up was easily my best decision of this year.

You also have to keep finding time for the people closest to you. The only people who get hurt more than you when you're stuck in the office for 12 hours days are the ones who love you the most. I don't know how I could maintain my personal relationships with my partner or our son if I kept the same work schedule I once kept.

Find Your Balance

Great. Now how do we go about doing this? Well, it's not easy, especially if work already has its talons in you. But, we can all start somewhere.

Here's a quick list of things to keep in mind when finding your own work/life balance:

Set your office hours.
- Do you work a 9-5? 8-6? Something like that? Figure that out and make it known.
Stick to your office hours.
- Now that everyone knows when you are available, don't accept meetings or answer emails outside that window.
Take mental health days.
- When was the last time you actually used up all your sick/pto time? Use it.
Find a fitness pattern.
- I can't tell you what to do here, find what's fun for you. I hear Crossfit is fun.
Say no more often.
- Not just at work. In home life too. Don't say yes to every night out, take some time for you to relax and have a quiet moment.
Calculate how much your time is worth.
- I'm going to harp on this one actually…

The last point is a big one. It's why I choose to pay someone to clean my house. Every two weeks, we have a service come out and do a full house cleaning. Sure, we pick up toys and vacuum during the week, but we don't spend time scrubbing showers and toilets and dusting the shelves. Here's why…

Bring On the Fuzzy Math

The company charges $100 for the bi-monthly cleaning. Using some rather fuzzy math, I make about $60 an hour. Cleaning our house takes more than 2 hours, plus, I don't want to do it. So, I'm saving $20 by paying someone else to do it.
That's it. That's my major decision making logic nowadays.

I'd much rather be playing with my son. I'd much rather be working on this blog. I'd much rather be just hanging out and doing literally anything else, rather than scrubbing my toilet. And I've got fuzzy math to back me up.

Next summer, I'm thinking about hiring someone to cut my lawn. I'm almost there, but I do still take some enjoyment out of that chore.

Why It's Called a Balance

I still take the occasional 8am meeting. I have to drop my son off at daycare early on those days, and neither of us like it. But, it's called a balance for a reason. There is give and take.

I also leave early on some days to pick him up and go to the pool. Give and take.

Learn what is most important to you. At certain points in your life and career, it may be your work. That's perfectly okay. Put in more effort and time to your career then, I did. Maybe you'll learn the same things I did or maybe you'll learn something different.

But understand that work is only there to allow you to do the rest of the things you want to do in life. Don't let it become the only thing you focus on.

Don't forget to focus on you.

Community Feedback

This came up again in a conversation in our CoderDads Slack channel. How do you value your time when it comes to your commute. I always fall back on the fuzzy math to decide on whether the commute is worth my time or not. It's a standard for me.

What are some standards for you when it comes to deciding your work/life balance?

What is it that you do again?

teachingtechleads — Fri, 20 Sep 2019 01:25:24 +0000

What is it that you do again?

I get this a lot. I mean, a lot. My partner doesn’t even know what I do for a living. She just says I work with computers. She’s technically correct, the best kind of correct. But, there’s a bit more to what it is a tech lead does.

Originally posted on TeachingTechLeads.com

It’s not glossy, it’s not sexy, it’s not something that is going to cause the person across the bar from you to go, “wow, tell me more.” But, I like what I do. I interact with a core group of people on a base level to help them achieve more. I get to play with new and interesting technology, but only after wading through incredibly thought provoking design and requirements sessions.

This post was inspired by the fact that every time someone says they are a tech lead, they probably mean something different. And one guy in particular asked me to detail exactly what it was that I did. So, Gergely, this is for you.

How I started

We were working on a project for a retailer known for “just doing it”. The team had grown in size and scope to the point where our current tech lead was becoming stressed to keep up with everything. He was wearing multiple hats, as we tend to do, and we commiserated over a few beers at our company event. That’s where he and the PM asked me to take on a junior tech lead role.

“Sure, why not.”

That project progressed with me taking over code reviews and acting as a bridge between our Spanish TL and our US based developers. I would get up early to chat with him for a few hours before the US team would get online, he’d tag out and I’d explain designs and new requirements that were coming up in the next sprint.

How I progressed

The second phase of that project, I took on a more full fledged tech lead role. It’s probably easier to just bullet list out my responsibilities than try to provide flowery prose:

Design sessions with the Tech Lead, Systems Architect, and Business Analyst Sprint Planning with Project Manager, BA, SA, and TL
Interfacing with external project lead(we paired with a front end team and they’d send a guy to our office for a few days once a month)
Code Review
Release Documentation
Training BA to prepare them for sprint showcases
Backlog grooming sessions
Pair programming with on site developers
I coded, every once in a while, usually after hours which turned out to be an awful idea

What you can’t tell from this list is the stress load. That list is only what I can remember, what I haven’t blacked out from that time. This was a year or so after my partner and I had bought our first house and was before our son was born, so… I had some free time.

My office hours were from 7-3, then back online from 8-12 or so at night. I did this through two projects, as we kept on resources from somewhere on the other side of the pond, and I liked being available for all members of my team.

Needless to say, I burned out after about 8 months of this.

How I am now

In my current environment, things are a bit different. Not by much, but there are some stark differences. The team doesn’t subscribe to a scrum methodology, so there are far less ritualistic meetings. That alone frees up at least 3 hours of my day every day.

Yes, I still take meetings, but they all serve a purpose. As tech lead, I meet with our internal clients and stakeholders to review requirements and present them with proposed solutions.

I still spend about half of my time as a second-degree coder, meaning, I am either working on a high level solution with the developer or reading through the code that they have completed.

I don’t have a backlog, instead there is a list of enhancement requests, but that’s up to the clients to decide what they want in the next release and how they want to prioritize that against what my team is currently working on.

I don’t have a retro every two weeks or a 6 hour sprint planning session every two weeks. Requirements are rolled out as they become agreed upon to the developers. And once they’re done with those agreed upon requirements, we deliver that release. The users know exactly what they’re getting, because they asked for it.

We only deliver what they ask for, nothing else. That seems simple, but you have no idea how easy it is to dismiss a change request or a “bug” when you can point directly at the requirement that was signed off on and say, “no, this is working exactly as you asked for it.”

How I see this going

I don’t think much else will change in the foreseeable future. I’ve been with my new company for just over a year now and I run a team of 2-4 developers. Whereas I used to have 6-8 developers and a whole lot of headaches.

I am the lead for one particular suite of applications. There are two streams of work going on for that application, and I shift contexts back and forth between them. I try to keep the devs from having to flip back and forth, because that’s my job.

Do I code? A little. I actually just completed a rule today that took all of 2 hours. It was a two line change, but I had to write up a failing acceptance test and then go check in on another developer in the meantime. I should have seen that coming.

Things come up, they always do. I had a C-level request for an ad-hoc report come in on Wednesday last week that completely botched a release because it stole a resource from his current task. But, that’s what we do.

We direct our resources in a way that gets the client the solution they require in the most efficient manner possible.

To everyone here

Are there any questions about the role of a tech lead that you want to know about? I'm constantly looking for things to write about, here and directly on my blog, so any questions or suggestions help me out a lot.

Thanks all!

Top Five Things You Need to Know Before Becoming a Tech Lead

teachingtechleads — Fri, 09 Aug 2019 01:04:32 +0000

Maybe you’re thinking about accepting that job offer or just starting to think about what the next stepping point in your career as a developer is. You don’t want to go full blown project management, because honestly, who really wants to be in that many meetings. You don’t want to be assigned tickets ad nauseum, because you’re pretty sure the company can hire an intern to implement most of these “enhancement requests”. The role of a Tech Lead seems appealing enough, but what is the path to get there?

Originally posted on TeachingTechLeads.com

I’ve made some light jokes about how I stumbled into my first role as a technical lead, but there was a lot of prep work that went into it. I had to figure out if I wanted to take on the role and then I had to figure out the path to get there. This is the short and sweet blueprint that I followed and the steps I took towards fulfilling every step along the way.

Know the Technology

I’m going to be blunt. You need to know your shit. You won’t be considered for becoming a tech lead if you don’t know the tech.

Do you need to be a 10x engineer, or whatever the fad name for the fabled unicorn developer is nowadays? No. You don’t even need to be the strongest coder on the team, I know I’m not.

But, you need to know the area that you’re going to be working in. This means a better than working knowledge on the following general subjects:

Design Patterns
Enterprise Integration Patterns
Scaling And then the niche language specifics for what you’re working on. For me, that was mainly the Spring Framework, Activiti, and Apache Camel.

Pretty specialized, but we were writing a workflow management tool for rather large merchandising company, and this architecture fit well within our company’s wheel house.

Did I know everything about Spring Framework? No, not even close. I delegated a lot of it away. One particular member of my team took over the Spring Security research and became a SME by the end of the second sprint. They were an extremely valuable resource because there’s no way I could be the person who holds all of the information. Just a good portion of it.

Know the Team

You can’t lead them if you don’t know them.

Not your first time through, a few projects down the road, sure. You can walk into a new team and use your prior experience to integrate yourself. But, your first time through, you need a team that you have worked with previously and trust you.

After a while, “knowing them” becomes “knowing their archetypes”.

You need to be able to lead all types of people.

People you get along with and people you don’t.
People you work alongside and people working remotely.
People who speak the same language as you and people who don’t understand sarcasm in the least bit.

So, get to know your current team and figure out what you can take away from every relationship that you’ve formed there.

Know the Project

You need to know the ins and outs of the actual project itself.

What is the expected release cadence?
What does the project manager expect to see weekly or bi-weekly?
What is in the pipeline for the next phase of the project(there’s always a next phase)?
What are the features that the client wanted but didn’t get?

You also need to know the people surrounding the project, as you’ll be interacting with them much, much more in this new role. No, you’re not a manager, but you’ll need to know how to manage up and manage expectations, tactfully.

Know the Environment

Every company has a particular working environment or climate.

You may be a shop that claims to be “agile-ish”, but still requires up front roadmaps and hard deliverables. Or maybe the architects are disagreeing with the overall technical approach of the CTO. Perhaps you can only get the ear of your product owner if you know how to get on the good side of a particular downstream employee.

These are all things you need to know.

No one can actually define this list for you, but you need to figure it out in order to be truly effective at your role. Because when you need to be an advocate for your team, there might be only one way to get everyone out of that ridiculous “mandatory” meeting. You better know it.

Know Yourself

This is a bit meta, by definition. You need to know why you want to do this.
I’ve alluded to the fact before, in this post and elsewhere, but I’m not the strongest developer on my team. That’s a small slice of impostor syndrome and a large slice of humble pie. But, that’s fine.

I know that I’m actually much better at helping people along than I am at producing perfect code. So, guess where I fit in pretty darn well? Into the Tech Lead role.

After my first two projects, I also know a bit more about myself:

I know that once I get over 4 developers on my team, I can no longer lead effectively.
I know that once I approach 60 hours for the 4th week in a row, I can no longer form sentences as well as I can on a regular work/life routine.
I know that my code reviews can become overly pedantic if my blood sugar is too low.
I know that my self deprecating humor doesn’t translate well with everyone, and I’m working on that.

In Conclusion

Without a concise knowledge of the technology you work in, the team you work with, and the project you’ll be capitaining; you won’t make it far. But, if you can’t take an honest observer role about yourself or your work environment; you won’t even make it out of the gate.

Once you can say that you are comfortable in these five fields, then you are well on your way to approaching leadership about the role that you want to fulfill.

This list isn’t exhaustive by any means, but it’s the bullet points I considered before accepting the role offered to me. I had been working with my local team for years. I had been working with the remote team for close to 6 months and felt rather comfortable with them. The technology had become rather secondhand to me and I was regularly helping the current tech lead with design sessions. Project management sat two rows over from me and the system architect sat behind me, so I knew the environment I was getting into.

Once I felt comfortable with the notion that I could add more to the project by not developing, I was ready to move out of my current role and become a tech lead. But how about you? What was the catalyst for you, or what do you think is holding you back?
Let me know below.

Four Quick Ways That You Can Find Time To Code

teachingtechleads — Thu, 01 Aug 2019 00:25:59 +0000

In Patrick Kua’s book Talking with Tech Leads, the commonly agreed upon statistic is that 30% of your time should be dedicated to writing code. In previous posts, we discussed how you are on a different cadence than your developers, as you really aren’t a developer anymore. So, how can you find time to code?

Originally Posted on TeachingTechLeads.com

It’s not easy, I won’t lie. I haven’t mastered it, so this is one of those posts that is a constant reminder to work to better myself. These are the four methods I’ve found that allow me to get my hands back into the codebase without taking away from the team.

Building the Scaffolding

This is the easiest method. And the least fun.

At the beginning of any project, there’s going to be a moment when you will want to set up the project structure. Whether that is doing everything by hand or running over to Spring Initializr and clicking a few checkboxes, it’s getting you close to the metal.

You get to inject your personal standards for folder structure and naming convention, as well as setup your maven/gradle module management.

Not a lot of code, but required work by someone. Might as well be you.

Prove Out that Concept

Who doesn’t love a good Proof of Concept?

It’s your time to spend a morning figuring out what a migration path from your RESTful API to a GraphQL API would look like. Or maybe you’re trying to benchmark just how long it will take to fill up all the local storage available given your slimmed down JSON response objects.

These are all questions that will lead the next phase of the solution design. Get a head start on proving out if your idea will work on the small scale before trying it in production.

Besides, allowing yourself a free 4 hour window to figure out just how something works is basically a paid therapy session. Savor it.

Refactoring

Technical debt accrues. It happens.

You happen to have an hour free between meetings? Why not look at extracting some common functionality into a strategy. Maybe take those two latest merge requests and see if there’s a way that you can define a default interface instead of two overly similar implementations.

I like to grab a team member and spitball ideas with, at least every week or so, and see if we can come up with a way to improve our codebase. We know that our behaviors are completely covered with both unit and acceptance tests, so there’s no harm in us refactoring existing implementations.

Keep in mind, refactoring cannot happen without that instilled confidence.

I’m currently in the middle of a personal goal to update our acceptance test suite from using the selenium remote control to the newer web driver implementation. It’s taken me close to 3 months to complete in piecemeal, but we’re getting there.

Pair Programming

Now this one is the controversial one. Not the idea of pair programming, but on whether or not you should be programming in this situation.

I’ll be honest, this is a major struggle for me with junior devs. When I am approached for help, I have to curb myself to not jump into the driver seat. I want to code, I know the answer and can do it faster than them…

But that doesn’t benefit either of us. I already knew how to do it. And they likely already knew that I know how to do it. They still don’t know how to do it themselves.

Treat pair programming sessions as a way to code through someone else. Develop your soft skills enough so that you can talk your pair through the exercise without ever touching the keyboard.

In Conclusion

You may get a chance to take on a story yourself, but depending on the team size, it might not be likely. You’re better off scratching that coding itch by following one of the four strategies listed above. And by finding an interesting side project for the weekends.

If you’re going to fill your 30% quota, which I personally can’t say I do, you’ll need to put out the effort.

You’ll notice that each of these tips lends itself to freeing up the team.

You’re building ahead of them so that they can hit the ground running.
You’re proving that the implementation will work in a small scale.
You’re improving code quality without affecting overall behaviour of the system.
You’re literally improving the developer who is pairing with you.

Your job is to enable the team, always remember that.

How to Stop Holding Your Team Back

teachingtechleads — Tue, 23 Jul 2019 18:26:31 +0000

This is a simple truth: if your team is running at full capacity, then the bottleneck that is holding them back is you. I’m going to take some time to try and outline why you’re holding your team back, and give a few clues on how you can maximize the team output.

Original Post on TeachingTechLeads.com

Setting Up the Scenario

Let’s say you have a team of 4 developers working on your project. There are 24 stories to implement, and using Little’s Law, we know that our team can complete a story every 12 hours.

You sit around in a meeting room and white board each and every story with the full team. You guys hash out basic patterns to implement and an enterprise messaging system that will keep all the pieces in constant, eventual, contact with each other.

Great!

The team heads back to their desks and is off to the races.

Around lunchtime the next day, you receive 2 pull requests. So, you start reading one, while the other devs twiddles their thumbs. About the time you finish the first pass on the first pull request, you are dragged off to a meeting.

When the meeting ends, there is a secondary response from the first developer on an open question you left on their pull request. And a brand new pull request in need of review from your third developer.

The fourth developer? They’re in the weeds and in desperate need a guiding hand.

You could head over to their desk, but at what cost?

The Math Behind It All

One developer running full steam at the rate of 1 story per 12 hours could complete this sprint of work in 32 work days.

That means the team of 4 should complete it in 8 work days. That’s a healthy two week sprint.

But that’s running at 100% efficiency. No downtime.

What about code review? What about a feedback loop around a refactoring that could strengthen your overall design?

Every time that you interject yourself into the equation, the numbers get pushed out. And not just for that one developer that you’re sitting down with, but for the whole team.

And don’t forget that you don’t work developer cycles anymore. A developer should be allowed a two hour window minimum to get into a good flow(I’ll find some research to back this up later). They can focus, they can put their heads down, they can get work done.

You keep management cycles now. You world is held together by 30 minute windows that may or may not be filled with meetings about something or other.

So, when you are needed, you may not be around. That developer with the question you could answer off the top of your head may be stuck waiting for an hour because you’re on a conference call where you’re needed for literally one 2 minute question and answer.

Because that developer was blocked, the rest of the queue is then pushed back.

How do you stop being the bottleneck?

Accept Your Constraint and Minimize It

You work with it and you work around it. You let your team help.

Here are some ways to keep things moving when you’re not there to intervene yourself.

Staggered Stories

Don’t start everyone out of the gates at the same time.

The best part about a continuous discovery/requirements gathering paradigm is that you always have work to do. When you run out of work, there’s a good chance that some more will appear in the backlog.

If you have a free developer, they are free to start looking in to any spikes or any technology questions you have about the new feature in the next sprint.

Individual Design Sessions

Sit down and do your design sessions with the singular/group of developers for a particular feature. As work comes up, sit down with the assignee and start blueprinting how to implement it. This isn’t the session that you and the architect had where you make broad gestures towards abstract notions.

This is putting names to services and defining the contracts.

This is drawing out the entities and the tables that will contain them.

The more the developer knows about the design, the less questions they’ll have during implementation. The less questionable code there is during implementation, the faster the code review will go. You two already decided on the implementation, the code review will be a cake walk.

Now, I’m not pushing for siloed development. Yes, this one developer will know this portion of the code better than their peers, but there’s a way to make sure that the knowledge is spread. Which is…

Peer Code Reviews

If you’re not there, have another team member read the code. This allows for someone else to be immersed in the code that they had no hand in creating. They will gain knowledge and subject matter expertise, while providing valuable insight that a second(third) set of eyes can provide.

In a project where I was leading over 7 different developers, I instilled a rule that each pull request needed the approval of a peer before I would look at it. This was because A) I was having a lot of trouble keeping up with all the code reviews and B) I knew that the first peer review would catch all the small things that I would have rejected the review for anyway.

Real Time Communications

In my current team, we have a rule. If you cannot figure something out within 20 minutes, you raise your hand. This is usually in the form of someone standing up and exhaling very loudly.

Worst case scenario, it is dropping a call for help into our team chat channel. This is broadcast to the whole team, including the leads and the architect. As long as they are actually looking at their chat notifications…

There needs to be a near immediate channel of communication between the team members. If there is not, then you are all boats adrift in the dark.

Say No to Meetings

This should be its own topic. But, you are not needed in every meeting you are invited to. I go to about half of the meetings that are proposed on my calendar. There are better uses of my time and if there is something that is needed of me, I should be able to tell from the agenda that should have been attached to the meeting invite.

Just learn to say no, politely.

In Conclusion

It’s tough, I know. The realization itself is the worst part. Every 30 minutes that you are stuck in a meeting when someone is waiting on you, you are blocking at least one developer from efficiently using their time.

You need to provide yourself ways to work around this restriction. Accept that the best use of your time is to enable your team. That’s what it means to lead, to make everyone else better.

If you have streamlined the process of getting work delegated to your developers, then you should be the bottleneck. That’s great! It means that the system is working. They are able to work without interruption and produce amazing code.

This means that they can do their job and you can get back to yours, which is to enable them and to progress the project towards completion.

Are there any other tricks you folks use to enable your team? I'd love to hear them below!

Top 5 Responsibilities of a Tech Lead

teachingtechleads — Thu, 18 Jul 2019 19:57:28 +0000

Yesterday you were a senior developer, happily spending your day working on the scenario or user story that had been assigned to you. When you sit down with your manager, they ask you to take on this new role of a Tech Lead and you accept, because, why not…

Original Post on TeachingTechLeads.com

What new responsibilities have just been added to your day to day life?

Gathering Requirements

Every project starts with someone realizing that they have a problem. That person complains to someone else, and sooner or later, they realize that IT needs to come and fix everything.

You’ll be meeting with the business, or the client, to hear about what their problem is. You listen, you ask questions, you take in as much information as you can before even thinking about proposing a solution. And then you propose it.

“Here’s how we can solve your problem.” Once they agree, it’s time to get to work.

It’s not enough for them to agree with the overall solution, you need for them to agree to the smaller nuances as well. The last thing you want is for them to see everything completed and not be happy with it.

Small feedback loops are key.

Designing the Solution

Once you have a sign off, it’s time to start putting together how this solution will work. At this point, depending on the size of your organization/team, you may be working alone or with an Architect of some sort. You’ll move from the abstract to the more detailed analysis portion of “how can we make this thing work?”.

Once you have a rough sketch of the solution and all its moving parts, your internal team process begins. My team uses BDD to implement our rules, you may use TDD to complete your Kanban tasks, or Scrum to iterate through user stories; that’s up to you. But, it’s at this point that you can start handing off units of work to your team.

Interfacing with Business

While the team is developing, you will most likely not be. We’ll discuss this in a later post, but you are no longer a developer. Get used to it.

What you are, is an interface. The client will have a question or a concern and they will want to talk about how a feature is being implemented. Or they will want to know when the next release cycle is coming along. They will try to talk to someone on the team.

That someone is you. No one else.

What you’re doing is freeing up your team to work.

Guarding the Code

Ahh yes, code. You won’t be writing it, but you’ll sure be reading a lot of it.

The codebase needs to be maintained. And you are the black knight, guarding the bridge to “master”, or “trunk” or the feature branch… whatever your branching strategy is.

Every merge request should be treated as a conversation with both the feature being implemented and the developer who implemented it.

Did they meet the checkstyle and PMD requirements?
Did they provide the necessary code coverage?
Is there an acceptance test that proves the feature is working as designed?
Did the developer implement the pattern you discussed during design?
Are they staying within the overall style guide of your codebase?
The topic of code reviews requires its own article, so we’ll dive in more later. But suffice it to say, you will be reading a lot.

Releasing the Product

Once every previously agreed upon requirement has been completed, you’re ready to launch! There’s just the task of writing release notes, connecting with QA, alerting the DevOps or SysAdmins or whoever is in charge of moving things through the pipeline.

When these people have questions, you’re their contact. Do they need to pull a WAR file from somewhere or update their docker images to a new release tag? Does QA need a run down of all the requirements and how they can test each and every single one?

And then once the product is released, we start the cycle over again when the client finds an enhancement they just need, or a bug that should be fixed in the next release.

Conclusion:

As a Technical Lead, you will be in charge of:

Figuring out what the problem is
Designing the solution
Explaining that solution
Delegating tasks and ensuring completion
Releasing the solution into the wild

That’s a pretty straight forward checklist that summarizes the software development lifecycle, shocking I know. But, when you take on the role of the technical lead on a project, you will be hands on from start to finish.

But don’t worry, as you won’t be doing it alone. In later posts, we’ll talk about your team and how they will be helping you along the way. Because, what is a Tech Lead, if they aren’t actually “leading” anything?