How to experience gradual improvement of knowledge while a newbie does .NET maintenance programming?

Question

I started my career as a software developer about 6 months ago. This is my first job, and I am the only developer in this company. I gained .NET knowledge by self study and also by doing some university projects. Our systems have old foundations based on an earlier version of .NET, and I'm starting to feel that I am not improving since I am a maintenance programmer here. Everything is old and my manager is not really taking any chances on gradually improving the software.

What is your opinion? What should I do? I am newbie and also work hard to find my way through. There is no other developer, not even a senior one to help me here. I need your advice on my situation. And one last thing, can I get a new job with doing maintenance programming? I mean don't managers say that you do not have the experience of developing a new software from scratch? I feel redundant, what do I do?

Answer 1

Well. Maintaining applications are a great way to learn. Having to work with a .NET 1.1 application would be terrible. But .NET 2.0 has most of the foundations that .NET developers use every day. Take this opportunity to learn .NET will before going on with things like LINQ, WCF etc. Learn from the mistakes that the previous developer made and how you solved them. If something looks wierd, study the code and come up with a better solution.

When you are fed up go looking for a new job.

As for your CV. Open source projects are great. Join one. It will also show that you can work on a remote team (better than solo coding but not as good as working in a real team). The most important thing with joining an open source project is that you show ambition and effort to learn and get better.

Answer 2

See my answer here for a .NET curriculum.

It is definitely hard when you are the only one. You have to push yourself. And the SE network of sites is fantastic. I consider it my own personal tutor and mentor. :-)

Another thing you could do is take some of your own personal free time and work on improving the company's software. Make sure you don't check it into the repository unless given permission, but this will server you in three respects - you will get experience writing better code, you get experience refactoring bad/old code, and you will (or should) get brownie points from the company.

Answer 3

Build something of your own in your spare time. Make the code open source, solicit feedback, incorporate new features. Thats how we all grow as developers.

Answer 4

(this response is biased by my personal experience - just one dude - take it for what it is)

It doesn't matter how much you know, if you aren't pushing to keep on the bleeding edge you wind up feeling left behind. People and culture at the workplace often help that to happen and make it seem rather transparent. I know I took it for granted until this past 2 years when I fell into the same situation, being the only programmer at a company. There is a good side and a bad side.

Good side: Learning on your own is hard because alot of the time you don't even know what you need to learn.

Bad side: it's too hard to do forever. There's too much utility in applying a group effort to something as complex as writing good software.

Since it's the start of your carrear, I'd say get yourself onto a team by 18 months. Staying at a job less than that causes a flag on your resume (more so when the economy is down).

Answer 5

Take a look at some books like "Clean Code...." and "Refactoring". You can definitely learn and apply good programming practices even if you are in maintenance mode. Next time they ask you to look at a bug or a problem see if your solution simply adds more "surgically placed" if-statements, or if your solution actually ends up with less lines of code than what you started with.

You boss might be against improving software, but if you need to fix something, you need to fix it. If it just so happens that when you fix it, you also remove 5 copy/pasted sections of code and create a class that self-contains the work that was done 12 times in various places, so that it is what it is. You don't have to do random improvements, but focus on specific areas that they ask you to work in.

I've done maintenance and it becomes horrible only if you start with not so good code and keep adding hacks to it to fix specific issue here and there until the code is even more of a spaghetti mess than when you started with. On the other hand, it's cool to see an existing piece of software after you fixed 15 separate bugs have same functionality, but contain 3000 lines of code compared to 9000 when you started working on it. And with enough practice, you could get to a point where you'll never see 16th bug written against this code ever again.

I'd say that if you care and want to learn, you could learn more about new development and writing clean clean/reliable/maintainable code by first experiencing what happens when others before you didn't do that.

Answer 6

1st, don't limit yourself to .NET, .NET only developers are a dime a dozen and worth about the same. Try mastering programming and not just a specific technology. I recommend learning c and c++ in addition to c# as these two languages will have the effect of giving you greater understanding of why .NET works the way it does. Also, I know that sometimes you may not have this choice, but when you can, get the hell out of a dead end job that only has you doing maintenance. Go find something where you are on a development team. If you can't do this, go join an open source project for your spare time. It is often very easy to get on and they are usually very welcoming of young guys wanting to learn. Email the project lead, tell him/her your situation, and ask him/her to point you in the direction of some bugs you can fix or some features you can implement. This way you will get the good experience and peer reviews that you need to become a good developer.

Answer 7

As others have said.... begin by creating a portfolio where you are utilizing some of the modern things in .NET.... don't rely on your employer's application, you might be waiting years.

I've made this mistake before. I spent a whole year working on a crappy old .NET 2.0 application for an employer who practically fed lies about us being to update the whole site from VB.NET 2.0 to 3.5 in C# over the course of a year, it was like a never reaching goal... (3.5 was the latest at the time).

Eventually we did actually get to write our first line of code (to convert the existing VB app to c# 3.5) ..... and then I got made redundant...

So I was back onto the job market, and I just couldn't believe how much I had missed being stuck on .NET 2.0..... we now had things like LINQ, Entity Framework, MVC 1.0 etc being mentioned on most job listings.... all of which I didn't know much about.

The morale is that it isn't really my employer to blame for this, I take the blame for not being proactive in my own time to learn these new features and create samples...

Right now, I have been working with a new employer on a ASP.NET 3.5 web application and there is no sign what so ever that we are going to ASP.NET 4.0 MVC anytime soon... but that isn't stopping me, I'm already learning about MVC 3.0 in my own time.

Ps. If you can hack it, stay with you current employer as long as you can, but do rest in the knowledge that it is 'OK' to quit if you really don't want to be there - I quit my first job (personal reasons) after 3 months... a few 'long-term' jobs later I'm still employed :)

Answer 8

Well, my answer is twofold.

1. No matter where you work or who you work with, you are ultimately responsible for your own career development. There are many ways to improve your coding - here are some tips. If you are on your own, especially at the beginning of your career, that makes it difficult. I would look hard for a mentor or mentors. That means attending relevant user-groups in your area, taking a course (online or in person) or maybe paying a CS student, or professor, or older programmer to tutor you.

2. For many, if not most people, bug fixing is an important precursor to fixing large problems and eventually performing program design. Even if you don't do maintenance programming, it's important to have done it, because most organizations spend most of their "development" dollars doing maintenance. Someone suggested "Clean Code" and "Refactoring" which are great suggestions, but it's important to notice that writing maintainable code has it's own (small) genre of literature - it's important!

Bug fixing gives you a tour of other people's worst decisions - which is important! But make sure to also take the time to look at the parts of the code that work, not just the broken parts. The areas that you don't have to touch are probably well written and will provide you with some positive examples.

I agree with others not to stay in pure-maintenance forever (unless you want to). Writing new code is a lot of fun, and generally a much more positive experience. But maintenance programming certainly won't hurt you, and having a few years of it under your belt will definitely make you a better programmer.

Answer 9

Informally talk to some of the managers in other departments and see how they feel about the current application(s). At least one of them has an idea for something new and will bring it up in the form of, "You know what I really need..." Obviously, you don't want to go behind your manager's back, but bring up the idea. You never know.

Adjust your mindset. You may not get to work on a new app, but new features. Look into learning how to refactor code. You manager will see it as a waste of time (don't fix it if it's not broke mentality), but this is just make it part of your maintenance.

Answer 10

Are there any tools you can make yourself that would benefit the maintenance of project you're working on? That'll help get you learning some new/different stuff and at the same time help make your daily job a bit easier.