Is okay to spend time learning at work?

Question

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).

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.