Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

It all started from here. I have been following Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)). The third chapter says that in Software Management:

  • You cannot give too much time to software developers, if you give it to them, then it is likely that extra time given to them will be filled by some other tasks (in other words, the developers will eat that time :)) Parkinson's Law

  • You can also not squeeze the time from their schedule because if you do that, it is likely that they will develop poor quality product, poor design and will hurt you in the long run, there will be a panic situation and total chaos in the project, lots of rework etc.

My question is related to the first point. If you don't give enough time then will the typical software engineer learn his/her skills?

The market is always coming with new technologies, you need to learn them. Even with the existing familiar technologies there are always best practices and dos and don'ts.

share|improve this question
    
I found a helpful link –  shankbond Aug 18 '13 at 14:18
    
when is a good time to learn ? - every day! –  c69 Aug 18 '13 at 16:07
    
@c69 that is exactly I am saying. Developers in my part of world spent almost 12 hours including the daily commuting activites involved in office. If You keep developers 100% to 110% loaded entire Year. Just guess how much can You self study in home, besides You have a family also to look after.... –  shankbond Aug 18 '13 at 16:47
4  
you can code 4 hours per day in normal mode. Everything beyond that is a crunch. While in general, crunches can be good, do not overuse them, unless you are in India, and have 100 new hungry kids waiting to replace your current staff, when they loose the edge, burnout or quit ;) –  c69 Aug 18 '13 at 16:54
1  
If you have questions/problems with your question, please ask on our Meta site. –  Thomas Owens Aug 21 '13 at 16:48

3 Answers 3

up vote 4 down vote accepted

Although MainMa's answer covers the points from the perspective of an individual contributor, there's also the project management perspective, which I began to address in the comments, but would like to expand on as a stand-alone answer.

MainMa's answer includes four points:

  • Formal training should be part of the job
  • The job itself should encourage learning
  • Code review should be a part of any company's process
  • Communication help's too

I can't disagree with any of these, but these points need to be considered very early in the project and, if using an iterative/incremental model, at the start of every iteration. In short, every project estimate should include time for learning, especially if the project is going to be using a new language, framework, or library. Tasks that need to be considered for "learning" include reading and understanding available documentation, working through tutorials and reading any sample code or open-source projects that also use the new tool, and creating any necessary prototypes to ensure the selected tool is actually appropriate for the project.

During a project, if you see opportunities to improve process or product quality, you should evaluate their impact on project schedule and budget and product quality and present these to the appropriate people (the project lead or manager, as an example). It's important to note that your first responsibility on a project is to your employer and the customer. Just because it's a good idea to incorporate something new into a process or product doesn't mean that it's possible to roll it out and also continue to deliver on schedule/budget.

As a general rule, I feel that one should conduct their learning off project time (unless it's learning something for the project and has covered under the scope of the project). Project time should, in most cases, be used to deliver value to a customer. That said, companies should be encouraging people to acquire knowledge and bring it into the organization. However, introducing it into a project, product, or process is something that needs to be estimated and budgeted from the start. Changing how work is done can be expensive and probably shouldn't be done in the middle of the project to reduce distruptions (see Steve McConnell's The Power of Process)

share|improve this answer
    
Thanks for shedding the light on this question. Actually in our organization we are loaded with 100 to 110% entire Year, so there is no scope of doing things/ improving them in off project times also take into account of Parkinson's Law which I mentioned. As for as the budgeting of new thing is considered, since they are relatively new and never done before, it becomes hard and nearly impossible to calibrate them. –  shankbond Aug 19 '13 at 17:02
1  
@shankbond It seems like the first step is not to introduce new things, but to improve your estimation. In a standard 40 hour work week, 40 hours shouldn't be budgeted toward project work. You have your status meetings/standups, emails/phone calls/other interruptions to flow, company meetings not about any project, and more. A 40 hour task probably doesn't take 5 work days to finish - it probably takes closer to 8. Fixing this should be a number one priority - don't overload staff and consider all aspects of the day in estimating workloads. –  Thomas Owens Aug 19 '13 at 17:19
    
It is a bit off topic but is there any trick by which I can persuade my Managers and senior to not overload me? –  shankbond Aug 19 '13 at 17:24
    
@shankbond No clue - I've never been in that situation. But every place that I've ever had has always had the idea of regular 1-on-1 meetings with your manager and regular project team meetings. Those are good opportunities to discuss problems, but it may be a company culture thing and it might be a sign to leave the company. Burn out is a serious problem and should be avoided. –  Thomas Owens Aug 19 '13 at 17:28

Often, the border between working and learning is not very clear.

  1. Formal training should be the part of the job.

    If a company where most projects were in Java wants to invest in Microsoft's stack, the staff should receive formal training This means that developers should follow lectures about .NET Framework, system administrators — about Active Directory and similar subjects, database administrators — about Microsoft SQL Server, etc.

    In the company I'm working in right now, there is no formal training. Developers are expected to learn things themselves (given that they work 40 hours per week). The result is that the lead product of this company is written in C# by people who don't know most of the core features of .NET Framework or C#. Lacking formal training in a company is shooting oneself in the foot.

  2. The job itself should encourage learning.

    If for the last five years, you worked on the same thing again and again, quit. The worst thing which can happen to a developer is to have a job where for years, the task remains the same. If you're a web developer and you've developed your twentieth e-commerce website, change something. Developing the number twenty-one would bring something to your company, but nothing to you. Salary doesn't count: with skill, you can always find a good job. Without, you'll depend on the current employer all your life.

    In all available tasks in your company, pick the most challenging ones among the ones you can accomplish. If you have some experience in a domain but want to have a deeper understanding, pick the task. Don't pick one in a domain you don't know anything about: this would be a loss of your employer's money.

    For example, if you work daily with C# but have used WCF only in a few small projects, when a new C#-related project arrives, try to have a WCF-related part of it assigned to you. On the other hand, don't ask to lead a project in Python if you have never wrote a single line in Python.

  3. Code review should be a part of any company's process.

    Code review teaches you humility, but also helps you learning from more experienced programmers. It's not the nicest thing to have your code reviewed, but at least it can be a good opportunity to highlight the bad practices, the lack of understanding of some concepts, and the ignorance of some tricks, syntactic sugar, APIs and new features.

    Reviewing someone else's code can teach you a lot too.

  4. Communication helps too.

    Since you probably work in a team, you have an opportunity to communicate and to learn things from others. Try to be in a team where you're the least experienced member. It's easier to be in a team where you're the best, but much less rewarding in terms of learning.

Aside that, look for jobs which let you have enough time to learn, but frankly, if you can learn stuff at work, keep your spare time for family, friends and hobbies.

share|improve this answer
4  
This covers most of what I would include in my answer. However, from a management perspective, there's also another point, that partly goes with 1 and 2: estimate time for learning and include that in project budgets and schedules. If you're estimating a project that involves working with something new (a language, a framework, a library, etc.), make sure your time to complete the task includes the time to read and understand the documentation, practice with any tutorials or read sample/existing code, and maybe even create a throwaway prototype. –  Thomas Owens Aug 18 '13 at 15:48
    
@MainMa Points 1,3,4 are not in my hand as for as point 2 is concerned this where I want to enhance my skills so that I am not dependent on the current company's mercy :) –  shankbond Aug 19 '13 at 15:39
    
@ThomasOwens If the technology is entirely new then the company spares some time allocated to us. But I think every day You should learn some new skill besides Your old daily routine. Say for example, I have been hearing about Test driven Development for about 2 years. In my company no one has every thought to working like that. So if in my current project I have to incorporate that, I will have to first learn (by myself with company that spares no extra time for increasing productivity), then incorporate in my current project, then ofcourse fail. –  shankbond Aug 19 '13 at 15:45
    
@ThomasOwens because when You introduce something new You get hurdles. It takes a very long time for a such company to accept new things. –  shankbond Aug 19 '13 at 15:49
1  
@shankbond It's a good thing to learn new skills and try to bring new ideas and best practices into your company, but doing it on the clock or in a manner that may impact project schedule or budget needs to be coordinated with your manager and the project lead/project manager. If you can improve product or process quality, those ideas should be proposed in the context of quality, schedule, and cost to the company. Your obligations to your employer and the customer come before your obligations to yourself towards personal improvement, at least when you are being paid. –  Thomas Owens Aug 19 '13 at 15:56

So much depends on the organization and how the teams are structured, but my perspective is...

There is project management and then there is management. It isn't the PMs responsibility to ensure that developers are achieving growth. That is the individual developer's manager's responsibility. They should discuss career development, set non-product-related goals, etc. This will impact the overall developer time that goes into the PMs calculations.

I also think that groups that adopt an agile approach are more successful than those that try a more waterfall approach as you describe. Asking for detailed estimates early on is generally a waste of time - they are invalidated both by the increasing knowledge that the developer has as he/she goes through analysis, design, etc., and also by changes, and the only thing that is certain in a project is that there will be changes!

Finally, leadership is important - the manager (not the PM) needs to motivate his folks, or the company needs to focus on hiring self-motivated folks, so that the programmers are excited about achieving the goals of the project. This plus an agile plan (and TDD) can really help avoid the work-filling-all-available-time issue.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.