(following up on a follow up)

So when you do have many people working under you - you need to make a decision: can you still write code in you dubious spare time?

Well, I COULD make the time.
Could I? I think so. It's a simple matter of neglecting some of you managerial responsibilities, and caring less about the code your developers produce. It ain't so hard. You just need to be in the right frame of mind.

But you really can't.

There's a phrase which states that a person will be promoted inside an organization to a position he will not be good at (simply because if he were any good at it - he will continue getting promoted). So the employees of the world can only expect to be good at what they do for a long time and get paid well in the process. In the end - we all stink (Six Feet Under is playing on the TV now. I think it has some influence)
So if you do want to continue getting ahead - you need to forego the antics of Christmas Past and look to the future. You enjoy writing code, but your REAL job is the other people's code and not your own.

What happens if you trust the developers too much and not check up on them? Well, it depends: if you have good developers they will just misunderstand or misinterpret your intentions (and it's bound to happen) so you'll have a great solution that you don't need; if you have lousy developers... well... you know.

I never realized how hard it is to persistently write one blog post a day. I tried it for a couple of days, I think, and then gave up (maybe it was three?). My hat's off to the psychos of this sphere like Roy, Oren, Raymond, Scott and all the other folks I can't seem to find the time to read.

* reposted due to misdating.

(following up on a previous post)

So when I did have only two developers on my team I was a coder like them. I used to assign myself the tasks I knew more about, and helped the others with their work. When I didn't want to disturb the workflow of my developers - I handled bugs which were on top priority instead of them. I simply had the time to do it along with the rest of my tasks. I learned new technologies, wrote complete modules in the system, mingled with other people's code (and refactored it when they weren't there to stop me) and basically - got my fingers dirty.

And dirt is important. I need the dirt to feel at home (rather poor hygiene, I know) and to be able to comfortably advise and talk about the stuff we deal with. I don't think I can be a good team leader in a project if I'm not familiar with the technology (granted, others would say that the implementation details should not concern the team lead. I strongly disagree.)

Things changed when I crossed the five developers line, though: I could not complete my personal programming tasks - I simply had no time for them. There are some tasks I'm still dragging to this day, which are my responsibility, and because I know way more about how to do them then other people - I'm reluctant to give them up (and, like always, it's not that the others developers have nothing to do - they have their hands full)

This hoarding behavior of mine has got to stop, I realize this, but the day I finally manage to pull it off will be a rather sad day for me. I'll be losing touch with code. I don't really know what happens next.

Now, don't get me wrong - I understand the correlation between managing a lot of people and the chance of further personal advancement. I don't think I'll be managing a division in Comverse any time soon, but this is a step on the right track.

But still...
Code...

No, it's not about "Ooh, I'm so lucky to do the things I love" touchy-feely crap again.

I sometimes find myself happy to be able to code; I really don't do it as often as I wished.
Leading a development team is a pretty goddamn hard work.

</OtioseStatements>

My development team has recently grown and more than doubled in size, and I came to a realization about the very essence of my job: leading a team of two developers is totally not the same as leading five. I used to just think this is a quantitative issue but it is qualitatively different, in what you think about, with whom you work, in the amount of time you have and with the scope of your interests (code related.)
It seems that with two programmers - you are basically just a developer-dude with seniority who gets to decide important stuff about implementation, design and a little about scheduling. When you lead six - your a technical-middle-manager (not Pointy-Haired, I hope) who advises about design, sets standards and attends meetings. That's about it, and GAWD that's plenty.

My former team leader was a veteran programmer who got promoted just before our roads crossed on the same project. It was just a one team development crew and he often took on tasks you'd normally expect a project manager or development manager to take. That team, too, started small and peaked at seven dev's. He and I wrote code together when the thing got started, so I used to think that because of the weird topology of that project - he had no time to lo later code and get technical. Seems I was wrong. At least from what I see about myself now.

I've got more to say about this. Tomorrow, same time?
It's a date, than.

I like weekends.
Don't worry, there's no big insight on "why", I just need to state that in advance.
I don't like working weekends.

I like my job. I like the technology. I'm extremely happy to be able to do what I like with my life.
Y'all are probably like that (blog readers and such, and let's face it - my blog ain't exactly Dilbert or XKCD. More like Maramduke)
I do like learning new stuff and reading technical articles and books in my free time.

</Exposition>

One of my teammates recently encountered a technical issue he could not resolve quickly, on a Thursday afternoon, for a feature he knew was urgent enough to finish. He told me he'll get cracking on it over the weekend and I simply told him not to. I think developers should have some "quite time", both on the "humane" level and also on a professional level - it's good to stop thinking about problems, and then return to them with a fresh slate, with the ability to criticize all the basic assumptions (the phrase "let it sink in" just didn't do it for me).
Nonetheless - the reason I told him not to work on it during the weekend was not because of the professional reasons. Personally, I don't like being told what to do, especially on weekends. I guess other people are like that as well.
So even though he himself has offered to do that task - I'd much rather offering him an easy way out than to let him feel he "had to" do it simply because he "accidentally" volunteered.

And I do appreciate his gesture. I do. I don't have any problems with people honing their technological skills on the weekends ("learn-stuff-make-smart. Booga booga"), reading books, articles and thechniblogs. It's probably very interesting to them. I know I do it because it interests me. But I think that being productive (and not get paid) over the weekend has a certain "odor" to it.

Anyway, I worked this last weekend. The quiet work environment did me good.

(No, I don't have an answer to that question in this post)

"A friend of mine has a problem": he gets too worked out about code. And design. And architecture. "He" usually holds a view about implementation of ideas which is "all or nothing": you either do it right or not at all, which often leads to a heated debate about the smallest of features.

When "he" was a developer - he could live with the fact that sometimes - he is absolutely right and his team leader has a different (and erroneous) point of view which simply overrides his absolutely 100% correct idea.

Since becoming a team leader he has noticed that more often than before - such arguments tend to go his way. Maybe because he has a louder voice?

Now, I don't mind admitting my mistakes. I can easily recall several times that after a discussion was over and everyone calmed down - I've retracted my arguments and conceded the other side's claims. So I'm not a total ***.

But is "putting my foot down" (on sometimes idiotic issues) worth it? There is a definite "loss of prestige" for a team leader when he ends a discussion using his authority. Sometimes it is better to just end the whole bru-ha-ha and get on with our jobs, I know, but when? I think that after we've explained ourselves several times - the argument has reached its peak. People need to absorb.

I ramble. I noticed. Sorry about that.
Also - this post ends midway. I guess I haven't thought about it enough yet. Sucks to be you, ah, readers. :P

I had not participated in many projects which had a POC stage, or joined projects after that stage, so I may be missing the point here.

Customers tend to have a "waste not want not" frame of mind: If we write code - it had damn well better be used in the production product. "We cannot afford games" so the programming teams should only write code which will stick. "Work smarter not harder" and all that crap.

I try to explain to my customers that code is a living being. I personally think that if I wrote a piece of code and didn't change it at least twice - I did something wrong (HACKed the use of that component or simply didn't use it enough.) Code should be "refactored to patterns" any time it's changed, and it should be changed a lot. Pretending that it is perfect is, as a rule of thumb, stupid. Therefore - I write the best code that I can at any given time, and this probably means that code that I write will be deleted or changed before it reaches production.
Enter the customer.
"We don't pay you good money to just to practice your typing" they say.

Usually I yell enough at them to make them understand the dynamics of code (or just to leave me alone), but what I often fail at is to make them understand the meaning of POC. It is, as I understand it, simply another project, unrelated to the "real" one except that it uses some of the same technologies, products and product interaction.

Customers usually see the POC as the parliminary work of the infrastructure team, and as such - the time spend on the POC should be deducted from the time needed for the project, and that's a hard concept to debunk.

Maybe we should be working differently? Maybe the POC should be written as the basis for the actual product components? Maybe a POC should not be billable to the client? Should the client pay for something which we do simply because we don't know if what we offered to provide can actually work? Or is there a magic bullet to make the customer understand? (Or am I just wrong?)

I pledge to you, the captive readers, not to "AutoForward" any product release without a very good explanation (or at least a lengthy comment on it.)

Damn, these last couple of weeks were horrible in the Blogoshpere - every Microsoftee (Israeli or otherwise) has "Announced" a product release or three, and most of my technical feeds were basically spam.

The concept of "Link blog" is ofter regarded with contempt, but I think that lately people have started to convince themselves that if you link to something "Job related" - you're in the clear. I disagree; linking to a funny news story or to a press release is just as spamish - do so at the peril of boring your readers.

(Title borrowed from Larry Osterman's post)

I've noticed that as technology advances, hardware becomes faster, and my average compilation time becomes shorter - I get more and more annoyed with my machine misbehaving or suffering from temporary hangups.

I cannot explain this in any other way other than: I'm getting old and cranky. I suspected it will have come to this, just not so soon.

What is really surprising is that fact that although I suffer from some performance issues with it - I still cannot stop using the Resharper. Amazing tool. You should get to know it if you don't already. And don't believe the hype about "VS05 has refactoring capabilities"; it's child's play compared to the re#er.

Oh man, the server is bleeping my naughty words. I feel like I'm on TV...

I think there are three kinds of blog posts I enjoy reading: the funny ones, the "new information" ones, and the "putting thing is order" ones.

I mean - I KNOW what drives me at my work, but it's nice to read posts like these which phrase it better than I could (and let us not forget this.)

What? You ask why I think I cannot phrase it better? Have you read the second paragraph on this post? Does it sound like it came from a man who can express himself good? :) 

So let's kick things off with some non-original content: Joel Spolsky from Joel On Software has written a nice piece about recruiting delevopers.

Now, I know I have a tendency to agree with him, but nonetheless - this article has nicly divided the deleveopers crowd in to four distinguishable groups by two parameters: Smartness and "Get Things Done"ness. Go read it.

I agrue that there's a another group: the lying basterds. They come in two varieties, the Highly Paid Consultant and the Brilliant Paula Bean. My beef is with them both and I can influance the hiring of none.

The consultants may often promise clients unimplementable stuff that we would later have to actualy implement, and when failing to do so (or do so promptly) will be the ones who have to provide answers (or be taken outside and shot). And yes, pre-sale is important; no, I don't think they should write all the application themselves; yes, some are WAY too smart for me to understand what they're talking about. Other times these HPCs just do a half ass work writing specs, and when the client is surprised by the end result - All I can say is that I was only following orders...

The "Paula Bean" kind is something that presents me with one of the biggest things I don't understand about the software industry: How the *** do these people manage to keep their jobs for more than a month at a time? I can guess we've all encountered a useless developer whose contribution to a project was null. Now, I can understand that the interaction between a team leader and the developer could "produce bad work" which results in... well, whatever. This is usually a one time thing and a brand new team lead will get better results from this programmer. But what about the inherently useless coders? When can we decide that a certain someone does more damage than good ("You ARE the weakest link, Goodbye!")? Why is it that usually after there's a consensus amongst the developers that this person is rubbish and should be let go, he is given a second chance by management? Joel has talked about the hardships in actually firing someone, but I think these reasons apply almost exclusively in the American scenario. Managers should be bolder in making these kind of personnel decision, in my mind.

Serenity Now!

Hi everyone, glad to see y'all here.

So I have a blog. Now what?

I guess I'll have to start filling in the blanks.

As your host, I'll be responsible for the posts and you'll be responsible for making me feel important. Just make sure y'all behave or I'll have you thrown out (No big loss right now, I know, but once Yahoo start throwing money at me...)

I can't realy remember what I was saying... ah yes, blog: I'm going to write this blog incognito, to prevent my big mouth from taking me down with it, so let's try to work around this. I will say that I am a team leader with some experiance in .Net and I'll probably talk mainly about those two areas: leading software teams and writing actual code.

I hope we have a blast (and I hope not to parish in the flurry of other "I-hope-this-won't-be-my-last-post" sort of opening posts)