What's the hardest part?

[Andy Hunt]

Things seem to have quieted down here a bit, so let me ask a *very* open-ended question.
What do you think is the hardest part of software development?
What frustrates you the most, and is the most difficult thing to learn?
I've my own notions for this, of course, but I'm curious to see what you all think.
thanks!
/\ndy
------------------
Andy Hunt
Author of "The Pragmatic Programmer: From Journeyman to Master

[Avijeet Dash]

nice question!
For me the hardest thing is to keep pace with technology.
I am in the industry for last 3 yrs, and I have lived through c, c++, java, html, javascript, servlets, jsp, ejb, jdbc etc etc.
The list never ends.
now there is requirement in weblogic, websphere, webfocus, cics other connection apis, god knows how many areas, tools, technologies.
adding to that the evolving change in process, methedology and patterns.
I find myself LOST.
to keeping my job secured, i should learn LDAP, Database Admin etc etc.
Is there a end to it!!!

[Mark Herschberg]

Excellent question!
I've got to disagree with you Avijeet. I think that's the wrong focus. Learning any particular technology (or tool, or methodology, etc) is a dead end. You run into the problem you're having, trying to keep up with the latest hot whatever.
I think the hardest part is communication. How many of us have been in the follow situation. Imagine a project where you give some requirements/specification to someone else (be it formal like a written spec, or casual, like a conversaton hallway). the other person goes off and does something totally different from what you expected, but it meets the specs you gave him!
Trying to get all your thoughts on paper. trying to get everyone on the same page. Trying to make sure you define the keys areas ahead of time, because if you don't, a developer may trip over the issue, and fix it locally, without thiking it's a bigger issue the group as a whole should address. Another developer trips over it elsewhere nad solves it under different assumptions.
As DeMarco and Lister suggest in Peopleware, most software issues are really people issues.

--Mark
[e-mail]
[This message has been edited by Mark Herschberg (edited May 24, 2001).]

[Andy Hunt]

Originally posted by Mark Herschberg:

the other person goes off and does something totally different from what you expected, but it meets the specs you gave him!

Did you know there are something like 27 ways to parse "Mary had a little lamb" depending on which word gets the emphasis??
This is a big reason why even detailed specs can fail.
/\ndy

[Avijeet Dash]

Andy:
whats r your notions of most difficult part of s/w development?

[Dave Thomas]

Originally posted by Avijeet Dash:
whats r your notions of most difficult part of s/w development?

Not yet! Let's continue gathering other people's experiences for a while. This will be interesting.

Dave

[Junilu Lacar]

I have to agree with Mark. It all boils down to communication. The worst project I have ever been on was one where there were 70+ developers, 30+ users and 20+ managers; $46M down the tube after 5 years, project cancelled. A lot of it had to do with poor communication.
The next hardest thing in development I think is getting people to break old habits. My current project is a pilot OO project using Java. The organization has had a mainframe-COBOL environment forever. While they are eager to learn OO style development, they are still hanging on to their old ways of doing waterfall-style SDLC.
It's hard to get people to accept the concept of iterative development because they have believed for so long that not getting everything nailed down up front will only give you grief down the road. I have given them the spiel about software being organic, that you need to grow it rather than build it, etc. Still, they are hesitant to break the mold and try IID.
It's a Catch-22: They want to do OO but they resist adopting practices that bring out the full advantages of OO because those practices are contrary to what they believe are the "correct" practices. "Yes, we'll do OO but we won't do iterative development and we won't do use cases and we'll have the testing phase at the end of the project, etc."
When I interviewed for this position, the client manager asked me what were the disadvantages of OO. My answer was that "it is darn hard to do right. You need commitment from management to accept change, commitment from users to accept change, and commitment from developers to accept change." And yet, change is the hardest thing for people to accept.
Junilu

[Andrew Shafer]

I think different people will have different difficulties based on there personalities, abilities and habits.
I personally love learning new technologies.
I have difficulty keeping my focus, getting lost in possibilities, instead of taking care of the necessities.
Having never experienced XP or some of these other production/design methods, I cannot speak from experience. Although, from reading, I believe having two programmers working side by side on the same code could be a benefit to all. I'd postulate a synergistic effect, especially if one personality tends to stay focused on the task and the other thinks outside the box. (some how I got off topic, imagine that)
Anyway, thats my vote for difficulty, keeping the program doing what it is supposed to do. (and keeping myself out of java ranch when I should be working is hard too)

[Junilu Lacar]

Would it help spur discussion to also mention Frederick P Brooks, Jr's "essential difficulties" of software development?
FPB Jr, in his 1986 paper "No Silver Bullet" says software is difficult because of:
1. Complexity
2. Conformity
3. Changeability
4. Invisibility
Although written 15 years ago, this still holds true and I think time has proven him correct. It's also interesting to note that he suggests rapid protyping, planned iterations, and "growing software organically, adding more and more functions to systems as they are run, used, and tested" as ways to address these essential difficulties.
I read "The Mythical Man-Month" after I read XPE and it just blew me away to see how almost prophetic "No Silver Bullet" was.
Junilu

[Sanjeev Arya]

The most frustrating thing in programming seem to be unclear and changing requirements.
Unclear: When the client is fuzzy about what they want the product to do. This is different from communication problems. I am talking about times when the requirements themselves are fuzzy.
Changing: This is even more frustrating when the clients see the product (maybe prototype), get a better idea of what they actually want ), then change the requirements drastically.
This can be a pretty subtle issue... if they really acknowledge the workmanship, applaud and encourage you to do it even better the next time around, then thats still ok. But if they try to pretend they have known it all along that this is not what they wanted in the first place, thats really frustrating.
I personally like learning new technologies too. I wouldn't want to code in the same technology for 5+ years.
The most difficult thing to learn is to keep the focus (on having fun ) in times of frustration.
Sanjeev

[Carl Trusiak]

Originally posted by JUNILU LACAR:
The next hardest thing in development I think is getting people to break old habits.

I have to agree here. The company I work for spent a huge amount of money for Rational Licences, training etc... and it's a fight to get the old timers to even consider doing a use case!

[This message has been edited by Carl Trusiak (edited May 24, 2001).]

[Junilu Lacar]

I think Andrew and Sanjeev raised a good point too about keeping focus.
This difficulty in getting focused also exists at an organizational level and the results are even more detrimental to the health of a project.
How many times have you seen developers trying to find things to do or doing "busy" work, griping about management not being to able find their behinds much less come up with a good, coherent plan that realistically reflected the work that needed to get done in the way it should be done?
A lot of projects I have seen are like that. Worse yet are those situations where managers try to do things "by the book" irregardless of the situation. They set up artificial schedules and tasks (I hate M$ Project for that) and ask developers and users to report progress based on them.
Meanwhile, the developers and users are looking at each other and the schedule, still having no idea of how to bring things together. In the end, they fudge the numbers on their progress reports giving misleading information to managers who then become blissfully ignorant of the real state of the project. People hate fudging the numbers on their progress reports and they blame and resent managers for making them lie.
That's another thing that really clicked with me about XP: it tends to keep people honest and focused.
Junilu
(stepping off my soapbox now)

Originally posted by Sanjeev Arya:

The most difficult thing to learn is to keep the focus (on having fun ) in times of frustration.

[This message has been edited by JUNILU LACAR (edited May 24, 2001).]

[Daniel Dunleavy]

My gripe is management...which goes back to the people issue.
There are so many problems which are created with the wrong person in charge.
Here are some major ones:
Every problem can be solved if I throw enough resources at it.
Trying to develop every project or solve a problem in the same way. Some projects have their own dynamic, and are driven totally differently. Yet these guys continue to try and drive that square peg in the round hole.
Unable to admit to mistakes. Sometimes you have to admit you took a wrong turn, and go back NOW. Don't wait until another 5 millon is wasted. I don't know how many times managers have come back to me 6 months later saying "We can't get this to work. What was that you said we should do a few months back?". Of course this is a month before its due, and you try and cram 6 months of work into a month.
I really think that teams should be self governing, and just let the results speak for themselves. Sort of elect a guy to hold the title, but he also must be more involved than most managers. And, most importantly, he can be impeached by the team. Lynching is optional
Sorry, I know that will never happen, but I like to dream sometimes.
Dan

[Mark Herschberg]

Originally posted by JUNILU LACAR:
The next hardest thing in development I think is getting people to break old habits...While they are eager to learn OO style development, they are still hanging on to their old ways of doing waterfall-style SDLC.
It's a Catch-22: They want to do OO but they resist adopting practices that bring out the full advantages of OO because those practices are contrary to what they believe are the "correct" practices. "Yes, we'll do OO but we won't do iterative development and we won't do use cases and we'll have the testing phase at the end of the project, etc."
Junilu

Your comments imply that iterative development brings out the best of OO. Can you elaborate? I would see OO vs. proceedural code as orthogonal to iterative vs. waterfall processes.

--Mark
[e-mail]

[Mark Herschberg]

Originally posted by Sanjeev Arya:
The most frustrating thing in programming seem to be unclear and changing requirements.
Unclear: When the client is fuzzy about what they want the product to do. This is different from communication problems. I am talking about times when the requirements themselves are fuzzy.
Changing: This is even more frustrating when the clients see the product (maybe prototype), get a better idea of what they actually want ), then change the requirements drastically.
This can be a pretty subtle issue... if they really acknowledge the workmanship, applaud and encourage you to do it even better the next time around, then thats still ok. But if they try to pretend they have known it all along that this is not what they wanted in the first place, thats really frustrating.
Sanjeev

This is a good point. However, I don't think I've been on a project where the requrements haven't changed. Often this is for reasons you named. (Side note: providing the user with screen shots ahead of time, it often helps.) My current space in wireless, and the market has changed every 6 months. It can't say it's anyone's fault for missing anything, that's the way things are. So it's not changing requirements per se, but rather a failure of people to balances those changes against the needs and resources available.
This is a subtle difference, especially since many people don't balance well, making the distinction blurry. But the key is that you shouldn't expect a project to not have it's requirements change. Rather, you should hope you have a manager who knows how to relate those needs to other constraints.
--Mark
[e-mail]

[Desai Sandeep]

Well two things that I found very difficult in software development :

1. Developers usually do not understand the time factor as a crucial aspect for deliverables.They get into "analysis paralysis" or "design paralysis" stage.They keep saying "Let us understand the system little bit more" or "Let us design further before doing actual coding".Some one needs to always keep then aware about the time factor and about deliverables.
   
2. Take any project, you would always see the developer complaining - "If and only if, we were given further training, we would have delivered a better solution".
   

Looks like this is a vicious loop.How do we counter this,Andy?
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 25, 2001).]

[Andy Hunt]

Originally posted by Desai Sandeep:

Developers usually do not understand the time factor as a crucial aspect for deliverables.They get into "analysis paralysis" or "design paralysis" stage.They keep saying "Let us understand the system little bit more" or "Let us design further before doing actual coding".Some one needs to always keep then aware about the time factor and about deliverables.

This problem arises because of the artificial delineation between analysis, design, code and even test. They are all the same thing -- all just different facets of the same activity. This is why waterfall-like processes fail: the act of coding gives you insight on the architecture. Writing tests suggests better ways to design the interface. All of these may point out flaws or omissions in the analysis.
The central activity to software development is LEARNING. We are learning all the time: learning from the customer what they want, learning their domain, learning the requisite technology, learning how the system you're designing behaves, learning how it behaves under load, during error handling, etc.
You can learn by drawing diagrams. You can learn more by writing code -- be it production code or prototype code. It's easy to draw a UML diagram and convince yourself that you've learned all there is to know about it. Rational will even "validate" your diagram and churn out a pile of code if you let it. But the code may not even compile, let alone do the right thing.
Learning by *doing* removes a lot of opportunity for self-deception.
As for the time factor; we're always overly optimistic. It's important to realize WHAT is supposed to be delivered. XP is good at this, placing the emphasis on delivering code and only those artifacts that the customer specifically wants because of their business value.

Take any project, you would always see the developer complaining - "If and only if, we were given further training, we would have delivered a better solution".

That's always true. We're always smarter today then we were yesterday, and the more we read and study, learn and gain experience, the smarter we will be tomorrow.
That's why you leave things flexible. That's why no decision is cast in stone. That's why we do all the 70 tips in The Pragmatic Programmer. Software is organic, because WE are organic. We learn, things change. The software must change with us. That's not an admission of failure, but a recognition of an opportunity.
That's the way it is, IMHO.
/\ndy

[Dave Thomas]

For me the hardest thing is to keep pace with technology.

This is tricky, because employers tend to be lazy when hiring. Let me explain. In reality, and good developer can pick up a new technology in a week, and be proficient in a month. Sure, there'll be little corners that we may not know as well as folks who've been doing it for 3 years, but in reality that's a pretty minor problem.
What's rare, however, are developers who are good at the fundamentals: abstraction, synthesis, communication, and flexibility. These are the traits you should work to hone, and these are thr traits that employers should want. Do they, though? Nope. Instead they advertise for people with "4 years Java, 3 years Oracle 8i in an EJB environment on Solaris with ...". That's lazy, and it hurts them. But even worse, it drives the market into specialization. It forcs developers to chase after depth, rather than breadth, certification over understanding. And that's wrong.

[Junilu Lacar]

Originally posted by Mark Herschberg:
Your comments imply that iterative development brings out the best of OO. Can you elaborate?

My reasoning goes back to software being more of an organic thing: something that needs to be grown rather than built. OO and iterative development are compatible because you can start by identifying major classes, build a skeleton, and grow the system from there. Software development is not a linear activity and OO development and iterative development reflect this non-linearity. There's a natural flow to it that is absent from the rigidity of the waterfall method. Procedural type programming should in fact also follow an iterative approach.
Junilu

[Dave Thomas]

have difficulty keeping my focus, getting lost in possibilities, instead of taking care of the necessities.

I think we're all guilty of that at times. It is certainly the cause of many project overruns. This is where team practices and individual practices can combine to help.
Some teams that we visit seem focussed. They churn out working code at a goodly rate. They are constantly checking stuff in. They're having fun.
Others just seem to meander. Some people are off adding more and more esoteric technologies to their little part of the code, bringing in third party libraries and tools. Others write far too much code because they don't really understand the requirements, so they think they'll cover all the bases "just to be sure". Still others get demotivated by the overall atmosphere, and slack off, reinforcing the problem.
In our experience, there are two major differentiators between the two environments. First, a good project will always ensure that everyone knows what's going on. This doesn't mean there's a requirements doc as thick as a phone book. It means that the team understands the problem they're trying to solve. They know their user. They have a clear idea of how things hang together. They have automation in place, so that communication costs less. And they review what they're doing constantly, aiming to fix practices that don't work.
Second, the good teams use feedback to drive themselves. They never start anything until they know how to tell that they're done. Are we going in to a meeting? Before we start, what are we going to get out of this, what answers do we need, what are the criteria to know we can end the meeting? Are we going to write a program? How do we know we're done: will we be running acceptance tests, will the customer sign off on it, will we integrate it with X, Y, and Z? Are we going to write a method in our program? How do we know it's done? Will it pass a unit test?
In great teams, feedback is pervasive.
And that's where focus comes from.
And the good news is that you can start at the individual level. Even in a team that's floundering, applying the basic principles here, and in the Pragmatic Programmer, will honestly help make your life easier and more rewarding. And who knows? Maybe some of it will rub off on the people around you.

Dave

[Avijeet Dash]

I must appreciate the level of discussion we are having here is really high. I have a feeling lot of experienced/knowledgable people are replying here.
I can feel what you people are talking about but still can't single out the points to remember and move ahead.
The most exciting thing for me is as its a evolving area, I feel like i can develope and cotribute in my own ways + derived ways to my team.
I am not sure my team (i am the junior developer) know abt XP, s/w development issues that we are talking about here or not.
we have started talking shyly about patterns sometimes when we get charged up, but we haven't talked abt refactoring, XP and other things.
when i say Design by contract, refactoring, light weight process, pair programming i am not sure people around me undertsnad it, appreciate it or not.
we talk about ejb, oracle, servlet issues but never talked about organic s/w development.
probably what i want to say is, whatever we r listening here are nice to hear, and i hope s/w development become more fun to handle with all these coming up ideas.
thanks everybody

[Mark Herschberg]

Originally posted by JUNILU LACAR:
My reasoning goes back to software being more of an organic thing: something that needs to be grown rather than built. OO and iterative development are compatible because you can start by identifying major classes, build a skeleton, and grow the system from there. Software development is not a linear activity and OO development and iterative development reflect this non-linearity. There's a natural flow to it that is absent from the rigidity of the waterfall method. Procedural type programming should in fact also follow an iterative approach.
Junilu

I agree with what your saying, but disagree wih your conclusion.
1) I think iterative approaches work well on many software projects, not just OO projects. (You seem to agree here.)
2) I think you can get all the benefits of OO withouth necessarily using an iterative process.
WRT to the latter point, let me elaborate. There are some projects (general smaller ones) for which waterfall works fine. I also believe iterative is generally a better approach. However, when I consider the advantages of OO programming, I feel those can be achieved independently from the process.

You've advocated a top-down approach (also promoted by XP). I think bottom up definately doesn't work. Middle-out is a nice way of saying, well, it's neither totally bottom-up or top-down; and not surprisingly the hybrid method is often the most advantageous. But I don't see how this approach necessarily makes the results OO programming any better. I think OO benefits can be achieved independently of the process use; although I will conceed that a bad process can hurt an OO (or any) project.
--Mark
[e-mail]

[Junilu Lacar]

Originally posted by Mark Herschberg:
I think OO benefits can be achieved independently of the process use; although I will conceed that a bad process can hurt an OO (or any) project.

Conversely, a good process helps an OO project. I think that being able to do OO (or any type of programming) well has a lot to do with the process by which you do it. If the process does not help you focus on the right things at the right time, you end up not doing the development well. In the case of OO, if you don't do it well, the code becomes non-OO thus you lose the OO benefits. Same thing for procedural/structured programming: you end up with non-modular, unstructured, spaghetti code if you don't do it correctly.
Also, I don't think I would consider XP as a strictly top-down approach but more of what you call a "hybrid" approach.
Junilu

[Daniel Dunleavy]

Originally posted by Desai Sandeep:

1. Developers usually do not understand the time factor as a crucial aspect for deliverables.They get into "analysis paralysis" or "design paralysis" stage.They keep saying "Let us understand the system little bit more" or "Let us design further before doing actual coding".Some one needs to always keep then aware about the time factor and about deliverables.
   
2. Take any project, you would always see the developer complaining - "If and only if, we were given further training, we would have delivered a better solution".
   


[This message has been edited by Desai Sandeep (edited May 25, 2001).][/B]

In my experience it is critical to get a good design, and most people know that. So sometimes delays happen in the design phase because they are trying to get it right. I don't think anyone, or at least anyone I have known, is oblivious to the deliverables.
What often happens is that too much is bitten off at once, instead of dividing it into manageble chunks. That way the coding can begin on one piece while some design is still being worked on. Of course, this necessitates choosing the right pieces to do when and the right dividing lines between each piece.
My approach has always been to tackle unknowns and the most complex as early as possible. You might push out a really small easy design first, to get everyone else moving.
Often I have seen time spent in the beginning on pieces where you have done it before and know how it will play out. Near the end there is a scramble for the the rest.
I am not sure why they are doing it. Fear of the unknown? or just trying to pump the other stuff out to prove they know what they are doing. But I think you really need a parallel process going on where you are showing some deliverables but not waiting to attack the real meat of the project.
Dan

[Frank Carver]

In my experience, the "hardest thing" varies with the team, with the project, with the company culture and many other factors.
The project I'm currently working for has trouble with requirements. Historically it's been driven by designers with a 'the users will just have to like what we produce' attitude, and there is still a very strong culture of always adding just one more speculative bell or whistle rather than actually releasing something simple and early. This team has recently become very "top-heavy" too, with something like twenty managers, meeting-attenders and hand-wavers for one or two developers.
Another company I worked for had a real problem with morale. It was a small arm of a major advertising group and existed mainly so the sales staff from the other group companies could claim to offer a "complete service". But the people selling our services knew very little about what we could actually do, and we were invariably vastly oversold :- "We've just won business from a major client who has a national TV campaign going live in two days; we've told them you have twice as many lines as you actually have, and we need a complete telemarketing system with interactive scripts, custom reports and staff training all based on this back-of-an-envelope I scribbled at a boozy client lunch yesterday". The company also used panic management and fire-the-scapegoats as essential tools, so it hardly ever succeeded at anything. I didn't stay long.
On yet another the main problem was "not invented here". The founder had started from nothing and was very proud of the product, but the product and the company could not grow because the founder had to be involved in every decision and everything had to be made in-house.
Another project suffered from "cover my ass". Each level of management added more and more headroom to every quote or estimate until a one man, two day job was quoted as a whole team for a month. Of course the customers went elsewhere.
All of these are people issues. Technology issues seem trivial by comparison.

[Mark Herschberg]

I would submit for consideration the hardest part is trying to figure out what the hardest part is. Each company, each team, each project has a different set of challenges: working with a new technology, communicating, trying a new methodology, training new members, coordinating across teams, working out the design details, setting expectations, getting a new manager, entering a new market, etc. Being able to recognize what the toughest issues are, and spending time on them (as opposed to spending the tme worrying about issues which aren't so critical to this particular project), is a tricky issue. If you get it wrong, you don't spend enough time on the biggest issues and they end up hurting you.
--Mark
[e-mail]

[Avijeet Dash]

Guys,
I just realized one more frustating problem and need your thoughts in this.

i am supposed to finish a module which has got dependency on other modules left right and middle. and the classes on which i am dependent are being developed somewhere else.
my code is full of commmented code which is waiting for the classes to be done and then only they can be built.
i am trying to overcome the frustration and trying to work smartly and get things done despite of huge dependencies.
how do you people manage this?


[This message has been edited by Avijeet Dash (edited May 29, 2001).]

[Daniel Dunleavy]

Avijeet,
if I have time I usually create some "stubs" which mimic the behavior of what I need. Obviously this takes time, but if you wait too long you may not have enough time to test. Create what will give you enough to run through and test at least 80%.
I usually do pretty good this way. Any changes I needed to make were usually when the other party deviated from the actual spec.
The other alternative is to work out a deliverable schedule from the other party(s). Letting you know what will be delivered when. Wait for the nearest at hand and create stubs for the late deliveries. Any departure from the delivery schedule should be reported to your superior, and let them know that it will impact your delivery date.
Dan

[Heath Lilley]

Let me just say that I decided to get the "Practical Programmer" on my own (this past Sunday) an am currently reading it. Love it so far.
For me the hardest part of programming are trying to figure out if "What i am currently coding IS the smartest, fastest, soundest... way to code it".
I mean I always try to think of what a guru would say if they were looking over my shoulder. The flavor of the day is JAVA and I currently am the most Java aware person in my shop (my boss likes the expression "In the land of the blind, the man with one eye is King.").
And that�s how it is. I have been programming commercially for about a year and a half. All of it has been in Java, I do understand the language pretty well (not quite enough to be certified, yet). However my problem is that I don't have the general software engineering experience to write "Kick Butt Code".
Everyone I talk to says that it comes with experience. Well I say "FOOBAR!!" I want...NO I NEED to write good code now.
I fully expect that your book ("The Pragmatic Programmer") will answer all my questions and solve all my problems.
On a final note, for the past 5 months I have been really focused on honing my skills and adding new ones (Running a Linux server at home, Trying to figure out shell scripting, setting up the Tomcat Java App server and MySql. It was nice to read in your book that these types of activities are a good thing.
Thanks
Heath

[This message has been edited by Heath Lilley (edited May 30, 2001).]

[Sanjeev Arya]

This thing has charged my cells a few times before.
How about this for a "difficult thing" to do... Imagine you are the manager of a new project, new technology, new team, new everything... How do you go about estimating how much time the project should take? How many people to have in what teams? How much $$ to charge? etc etc etc.
I am assuming there comes a day in every programmer's life when she/he has to deal with difficult answers to these simple questions. There are so many minds, cultures, schedules, and budgets to work with, I wonder how many projects ever get done on time and on budget. I really admire the work managers of successful programming teams do.
Maybe fellow ranchers can relate their own experiences on projects they have been involved with. How they got things done? or how they were part of successful or unsuccessful projects? I found Sheriff Frank Carver's message in this forum especially enlightening. Anecdotes like those really make my day
Sanjeev

[Daniel Dunleavy]

Sanjeev,
If you look at my earlier post, I mention tackling the unknowns. You should have a pretty good idea of the stuff you've done before, but it is hard estimating a new technology or anything else with which you have no experience.
So its imperitive to start doing research as soon as you can in this area. Then try and create something small and see how hard it is to do. Then this estimate is based off of these results.
Dan

[Julia Reynolds]

What a lot of these posts list as problems: communication, management, bad time management by developers, are all symptoms of a bigger problem, weak leadership/supervision skills for many first line technical team leaders. I have never seen a course or a recent book for team leadership for software developers. This is where our industry really falls behind older career paths, we don't recognize the importance of leadership skills and we don't address how to develop leadership and management ability in young developers.
Julia

[Avijeet Dash]

I fully agree with you!
The profession without a good leader/team is more and more mind numbingly boring.