Christopher Warner "So, it's not like the code is my brain; keep it"

Forget Agile, try Software Engineering.

Here are some tips on my new methodology in no order for software engineers and management. It's not XP/Scrum or any take on Agile because NONE of this is Agile in definition, manner or anything else. I like to call it, "Software Engineering (or SW for short)". I'm gonna make this short and I'm not going to qualify anything because I don't feel like I should have to.

1. Should you need someone to tell you to chop up your project into smaller units that are more easily digested? You're a bad manager/team lead/leader/whatever you are calling yourself. Needless to say a two or three year old is smarter than you and that MBA money went to waste.
2. If something is a smaller unit, that doesn't make the problem you are trying to solve through programming or anything else any easier.
3. If you need someone to tell you that you need to sit down and discuss what you plan to do before you do it? You're a bad manager/team lead/leader/whatever you are calling yourself.
4. If there are more bad than good things to say about something. It is rotten, throw it out.
5. No external force can run your company better than you and your employees.
6. Team building involves no methodology, it's a constant reassessing and making tough decisions. You want to make your weak programmers strong and reward your stronger programmers appropriately. If you need someone to tell you this. You're a bad manager/team lead/leader/whatever you are calling yourself.
7. If you are a programmer that can't say "I don't know, i've never done it before" or "This will take too long for X reasons" and/or "I don't know anything about X". Grow some backbone, you seriously aren't all knowing either so stop acting like a dick.
8. If you are a manager practicing Agile in any context. You're a bad manager/team lead/leader/whatever you are calling yourself.
9. There's nothing Agile about agile; Work is work, someone has to do it no matter how you cut it up. Agile doesn't make your resources work faster, more smoothly or any of that.  Building a comprehensive team does that; not some methodology.
10. Why can't you all be like Google and have the best programmers/admins working for you? You don't reward or pay a decent salary, and then on top of that you use crappy ass tools. Google is only successful because good programmers decide to work for Google; not because they have some secret sauce. That's how it works for ANYTHING. When the best people want to work for you well then you're gonna corner any market they are in. If all of Google's programmers left tomorrow they'll be a closed shop soon as those programmers go to Doogle.com or whatever.
11. How can I get the best programmers working for me? Choose the best tools and only the best tools. They will come looking for you; guaranteed. In your next job posting put "We like to use these tools, because they are the fucking best most awesome kickass tools available and we are building great shit." Also, i'd recommend not having HR write up the copy and less the profanities. Keep it simple, short and to the point. See what type of reaction you get.
12. Software engineering is mentally draining. It's not like filing papers. It isn't rote, so you can't treat your employees like it's some factory line.
13. The best feedback you get is from your programmer and if he/she gives you a comprehensive reason on why X is horse shit and it makes sense. Heed that warning.
14. Here's a typical stakeholder request. "I want to go to Mars". Here's a typical agile response "Lets break that story down into tasks and see how best we can do this if possible or break the overall problem into multiple sprints". Here's a typical Christopher Warner SW response "Well, I don't know if i'm in the right room at present but this is not fucking NASA, there would have to be a lot of work to get there. Maybe you should think about getting to Florida first".
15. Here's a typical Agile question "If you're in space and lost your tether and you had X tools which one would be best to use in aide of saving your life". Here's a typical agile response "The gun would be best". Here's a typical Christopher Warner response "You're fucked". It doesn't matter what tools you have at that point. The idea is to NEVER lose your tether so you never have to make that decision.
16. How do I know I have a good programmer/admin? He or she is usually busy getting shit done, and pretty much needs little to no management. They tell you what's going on, how things are progressing. What issues problems, concerns they may have etc. Pretty much everything is quiet on the front when they are around.
17. How do I get a team of good programmers? Good programmers will want to work with good programmers. Primarily because when one gets lost it pays to have a decent wing man or someone who can say "Welllllllsssssstttt this isn't working because you're a fucking idiot and wrote this module wrong, you're a dumbass. We'll work it out over lunch.. you know what?? lets finish this in X's office she's working on some similar shit; we'll order up. Bang this out and then hit the gym, after the beer you buy me. It always taste different when you buy it".
18. How do I reward my team? Contrary to popular belief, money is on the top of the list but sans that proper recognition. Beers and pizzas and all that shit, save it for highschool. At the very least offer expensive liquor, we are all adults here.
19. How can I be a better manager/team lead/leader/whatever you are calling yourself? Make sure the road is paved and fill in potholes. When something from the top comes down that is horse shit? Say "This is horse shit". Don't go back to your team with a "This is horse shit but we have no choice."  Say "This is horse shit, I said it's horse shit and I explained the detrimental waste of fucking time. They still want to do it. Of course, you guys are free to do something more awesome and when asked I'll show them more awesome with a, my apologies, I guess this more awesome thing I have right here will have to suffice" or "Sorry we just can't fucking do this stakeholders.. It's just not possible for X reasons, the top one being that I know my job better than you and this request is simply in management lingo, UNpossible". Wrap that in termination free language; unless you happen to be in a mood in which case have another job already lined up and be sure some of your team can come. Don't want to abandon them.
20. "I don't know anything about computers I just want a measurement of when I can expect things!" When it's done, or accept variable estimates. Unless for some reason you believe the art of writing a program to be a measurable unit of work. In which case, let me explain. Writing a program is much like being an artist. You start with a blank canvas with a couple of constructs and then you have to take whatever came out of the human MIND and create a reality out of it. Think it's easy? Think of anything you have never built before until now.. Now go build it, but before you do. Tell me when it's gonna be done. I'll wait.
21. Anything successful takes a long time of proper foundation building, team building and regression. If you don't have that or experience it. You will not be successful. It's that simple there is no methodology or luck involved besides hard work and building a good team. FOR ANYTHING.

Ok that's enough. I hope you apply "Software Engineering" as a method to your next project; even if it isn't software.

About Christopher Warner

Christopher Warner is part genius, part idiot. This makes him well balanced. He's worked on numerous opensource projects with great people and has generally led an eventful and fulfilling life. He hopes to retire an old man in a rocking chair should he be so fortunate.