New (6 months) junior software developer in a .net shop. Haven't finished college yet. Only briefly touched on .net during the degree (Java degree).

There are many parts of the .net framework (along with 3rd party libraries) that may be useful to the tasks to which I have been assigned.

Is it generally acceptable to take time during a project to learn how to do the assigned tasks more efficiently? Even if it means taking a risk (such as trying out a 3rd party framework that may or may not be utilized...depending on how well it goes)?

Or is it better to flounder through the tasks and learn how things should have been done when there is downtime between projects?

There is no way for me to get a mentor, since I'm the only one who knows the technology (WPF) with which I work (which may sound bad, but we only have a handful (6-8) of developers, none senior).

  • 6
    "...when there is downtime between projects" there is never downtime between projects. Learn what you need to accomplish the task at hand, and estimate for it accordingly.
    – zzzzBov
    Feb 22, 2013 at 19:55
  • 5
    This is quite helpful - it also applies here.
    – enderland
    Feb 22, 2013 at 20:00
  • @enderland Thanks for the link, it is quite helpful. Feb 22, 2013 at 20:05

5 Answers 5


As long as your learning time (things you're learning beyond the scope of the current project) doesn't impact project deadlines or other deliverables, being proactive in learning things that will help you improve your productivity and/or the projects you're working on will be seen as a net positive.

But remember: your job is to get the product delivered to the specifications/requirements you're given. Often, you'll be faced with the dilemma of "it works, but I see now I could have done it better." Don't do this unless you can justify the time required, and there won't be an impact on any acceptance testing or project deadlines. Make some notes for yourself, and the next time you're working in that piece of code, take the opportunity to make it better.

Read your job description carefully. Mine (I'm not a junior developer, but I've had similar lines in every job description I've had throughout my career) has one bullet point which speaks to this directly:

Continuously follow and seek opportunities to improve development standards & practices, technical designs & architecture and governance structure.

In short, it means that part of my job is to do exactly what you describe.

  • The learning hasn't affected deadlines at this point, but part of my uncertainty comes from being new and not knowing if the things I am learning will pay off as a net positive down the road. Has it for you (this could be a different question in itself)? Thanks for your well thought out answer. Feb 22, 2013 at 19:58
  • Absolutely it has. The best recent example I can think of is learning PowerShell. I took it upon myself to learn it, and since doing so I have been able to automate a large number of things in a "lightweight" fashion (not requiring building an SSIS package or a full application, for example), and I've been able to demonstrate to others (even/especially people outside my group) the value of using that tool to achieve the results they need in their jobs more efficiently.
    – alroc
    Feb 22, 2013 at 20:04

Is it generally acceptable to take time during a project to learn how to do the assigned tasks more efficiently?

Yes, it is. It is normally expected that you lookup documentation and learn more about the craft during working hours.

This includes learning about and trying new tools (libraries, IDEs and other tools).

is it better to flounder through the tasks and learn how things should have been done when there is downtime between projects?

There is always something to learn from existing projects - this is also part of learning, only a different aspect of it.

You need to determine for yourself which of these would be most beneficial for the company - perhaps discuss this with your manager. In some ways, learning new tools and techniques is more valuable than looking back, though there is much to be said about introspection and retrospection - learning to avoid the mistakes of the past.

  • I have been learning and trying new tools, but have felt very insecure about since I wasn't sure if I should be doing these things at home. Reading your answer makes me feel more confident about how I have approached things. Thanks :) Tried to vote you up, but I don't have the reputation yet. Feb 22, 2013 at 19:53
  • @narohi - The point that alroc makes in this answer is also important - don't let learning take precedence over delivering.
    – Oded
    Feb 22, 2013 at 19:58
  • Like most everything in life, it appears that the middle road is the way to go. I'll try to find that balance! Feb 22, 2013 at 20:01
  • Learning at home is valuable, but if you're doing it solely for the advancement of your employer (and not your own personal education/development), you're essentially giving the company all those hours. I'm starting a project at home for my own personal enrichment, but I also expect to learn things that I'll be able to apply at work as well.
    – alroc
    Feb 22, 2013 at 20:39
  • I see...now I need help on something else. How do I accept one answer? Both supplement each other and address the issue from different angles. Guess I'll have to flip a coin. Feb 22, 2013 at 21:24

My rule of thumb is to spend 30% of my time plus or minus learning new and better ways to do things (or increasing my understanding of things we're already doing). The way I look at it is, if I take ten minutes to learn a technique that saves ten minutes, then if I do that thing once, I've paid for the time. If I take 2 hours to learn something that saves 10 minutes, I have to do that thing 12 times to pay for it. But if it's something I do often, that can be really worth it.

At first, 30% will probably not be a realistic amount of time for you to devote to this. But over time, the time you've invested in becoming more efficient and better at your job starts to accumulate to the point where you can decide for yourself what the appropriate balance is between doing the work and learning to be better at the work.

One of the things that I find is that I sometimes spend more time learning new things when I'm under deadline crunch, because the skills I currently have won't allow me to meet the deadline. These crunches have had some of the biggest impacts on my productivity over the long haul.

  • 1
    This approach had made me incredibly knowledgeable and productive in my own life.... plus it keeps you a lot more interested in work.
    – enderland
    Feb 23, 2013 at 3:32
  • Thanks for the practical rule of thumb and seasoned advice! Feb 23, 2013 at 14:56

Is it generally acceptable to take time during a project to learn how to do the assigned tasks more efficiently?

This, definitely this. The same way that when you solve a bug you solve the ROOT, not a symptom. Take the time out when approaching a task to find the right tools for the job, to read up on the API. It almost always will save you time in the long run.

Even if it means taking a risk (such as trying out a 3rd party framework that may or may not be utilized...depending on how well it goes)?

Not so much this. Remember that you're part of a team, try to work with them as much as possible, you don't want to build a rep as the green guy that runs off and makes massively complicated shit that no-one else understands.

You should be seeking to immerse yourself with a deep understanding of the technology being used in your current sources and by your current team. You want the rest of the team to feel relaxed about reading your code, not apprehensive. So if the team is using Postgres SQL for everything, then use Postgres yourself as long as its good enough for the job. If you want to use something funky like MongoDb then get buy-in from the rest of the team first by discussing it with them.

While your junior status might result in you losing out in some of the decisions made be sure to take note of both the benefits and the pitfalls of the current technologies used. Seek to champion changes in the culture that you think would be beneficial. Be proactive about recommending beneficial technologies with convincing reasoning.

Before long you'll be one of the go-to guys for new ideas and technologies but don't expect the transition to happen overnight.

  • +1 for finding the root cause and the best tools. Sometimes taking the time out to study a framework that the team may not be ready for can allow you to incorporate some of the concepts, which can help bring the team up to speed for using that or a similar framework in the future, so it can still be worthwhile. Feb 23, 2013 at 2:44
  • I'm all for new frameworks but as a junior position with six months in he needs to be careful he doesn't get a rep as a hothead that just wants to play with the sparkly toys. Buy in and as you say studying to help the rest of the team appreciate the gains and possibly lack of risk are the best ways to mitigate it along with trying to be as "unpushy" as possible. Feb 23, 2013 at 3:17
  • I've seen some "fresh outs" make a huge name for themselves as whiz kids this same way. So it all depends on where you land and what the culture is there. But in general, you're right :). Feb 23, 2013 at 3:22
  • Aye, it depends on how receptive the culture is. I've seen people act dismissive towards those who they felt "have not earnt their stripes yet" if they're too pushy with new tech. Feb 23, 2013 at 3:35
  • 1
    Great advice, thanks! For a bit more context in my specific situation—there isn't really any team to be concerned about adopting the tools I am trying out. Everyone has a specialized role in our small department, and somehow I ended up as WPF front end guy (Service-Oriented-Architecture). My code is hard to follow, regardless, since nobody has MVVM familiarity. Because of this, it seems that I have liberty to use whatever tech I want as long as I get the job done. However, I still need to consider the programmers that have to maintain my code in the future. Feb 23, 2013 at 14:52

Your boss is going to ultimately decide, so I would make sure you accomplished two things:

  1. Finish the things your boss wants you to get done on time.
  2. If your boss allows/expects you to improve your skills (hopefully they don't want you to be a jr. dev for life), make sure you're learning what they think is important. There may be plans to work with a different technology stack. Those who are proficient may suffer at this firm.

Do your best to open and maintain the lines of communication. Know what is going on in your boss's world.

Leaders of disfunctional teams rarely get promoted at quality companies. If he/she can't get promoted, you can't get promoted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .