GTD when you’re only a grunt

Table of Contents

1. GTD when you’re only a grunt

https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-youre-only-a-grunt/
Establishing an excellent software culture, following best practices when you’re (almost) the only one who does it

1.1. Just Do It On Your Own

1.1.1. Strategy 1 Just Do It

A lot can be done to improve the project just by one person doing it.

1.1.2. Strategy 2 Harness the Power of Viral Marketing

Many of the Joel Test strategies can be implemented by a single person on an uncooperative team. Some of them, if done well, will spread to the rest of the team.

  1. Start use a system on your own and share its benefits with the rest of the team.
  2. Then when they have problems that your system can solve, they’ll come to you for help.
  3. Eventually, they’ll see the value and start to use the system as it was intended

1.1.3. Strategy 3 Create a Pocket of Excellence

1.1.3.1. Write schedules and specs

The team won’t make schedules? Or specs? Write your own. Nobody’s going to complain if you take a day or two to write a minimal spec and schedule for the work you’re about to do.

1.1.3.2. Recruit good candidates to join the team

Get better people into the team. Get involved in hiring and interviewing, and recruit good candidates to join the team.

1.1.3.3. Find the good people

Find the people who are willing to improve and capable of it, and get them on your side. Even on poor teams, you’re likely to have some smart people who just don’t have the experience to create great code. Help them out. Set them up to learn. Read their code checkins. If they do something stupid, don’t send them a snooty email explaining what’s stupid about their checkins. That will just make them angry and defensive. Instead, innocently report the bug that you know is the result of the checkin. Let them figure out what’s causing it. When they find the bug for themselves, they’ll remember that lesson a lot better.

1.2. Strategy 6 Don’t forget to write code (7 hours coding/1 hour mantaining)

None of these strategies work if you’re not really an excellent contributor. If you don’t write good code, and lots of it, you’re just going to be resented for messing around with bug databases when you “should be” writing code. There’s nothing more deadly to your career than having a reputation of being so concerned with process that you don’t accomplish anything.

1.3. Strategy 4 Neutralize The Bozos

Even the best teams can have a bozo or two. The frustrating part about having bad programmers on your team is when their bad code breaks your good code, or good programmers have to spend time cleaning up after the bad programmers.

  • Resist the temptation to rewrite bad code, neutralize this moron by reporting bugs until you can’t find any more bugs
    What if they are no bugs, and it is more of an architectural issue? It would only slow down future developments

1.4. Strategy 5 Get Away From Interruptions

All happy work environments are alike (private offices, quiet working conditions, excellent tools, few interruptions and even fewer large meetings).
All unhappy work environments are unhappy in their own way.
The bad news is that changing the working environment is almost impossible in virtually any company.
Long term leases may mean that even the CEO can’t do anything about it. That’s why so few software developers get private offices. This hurts their companies in at least two ways.
First, it makes it harder to recruit top notch developers, who will prefer the firm that gives them cushier conditions (all else being equal).
Second, the level of interruptions can dramatically reduce the productivity of developers, who find it impossible to get into the zone and stay in it for any length of time. Look for ways to get out of this environment. Take a laptop to the company cafeteria, where there are lots of tables that are empty most of the day (and nobody can find you).
Book a conference room for the whole day and write code there, and make it clear through the preponderance of checkins just how much more work you get done when you’re in a room by yourself.
The next time there’s a crunch on and your manager asks you what you need to Get
This Done By Tomorrow, you know what to say. They’ll find you an office for the day.
And pretty soon they’ll start wondering what they can do to keep that productive thing going year round. Come into work late and leave late. Those hours after the rest of the company goes home can be the most productive. Or, if you’re on a team of developers who regularly come in late, get into work at 9 am. You’ll do more work in the two hours before other people come in and start bothering you than you do in the rest of the day. Don’t keep your email or IM client running. Check your email every hour, if you want, but don’t keep it running.

1.5. Overall

You can make things better, even when you’re not in charge, but you have to be Caesar’s Wife: above suspicion. Otherwise you’ll make enemies as you go along.
If one is involved with a famous or prominent figure, one must avoid attracting negative attention or scrutiny. Julius Caesar allegedly used the phrase to explain why he divorced his wife, Pompeia.

1.6. The value that senior engineers provide, and a few reasons to stop worrying about your technical skills becoming obsolete

1.6.2. Juniors

Juniors don’t know enough to:

  1. offer resistance to bad project plans (bad managers prefer them because of this)
  2. trust and overly willing to accumulate a mountain of technical debt
  3. This creates a false sense of productivity that falls apart when they never ship good software, but it can take a lot of time specially if there is a lot of staff turnover

Author: Julian Lopez Carballal

Created: 2024-09-16 Mon 05:18