Tips for Junior Programmers

I'm in a situation where I got a job as a developer and there is no mentor or anything. This is my first software job. I'm 24 and working on a BS in Computer Information Science. I have experimented with some languages on my own time, took some classes, and did a few IT internships and software is definitely the career for me. I didn't lie about anything on the interview process and it was a long exhaustive one.

It's basically a regular full-time position. Everyone is much too busy to help and I'm on my own. So far I've been going about it well and learning quickly. I do the same type of work as everyone else. It is Java and C#/.NET. I develop and support a few apps among a host of other things.

What I'm concerned about is how will this lack of mentoring affect me in the future? I'm sure there are others out there who started from scratch with no help. I would like to hear your experiences and tips.

EDIT: At this point my only source of help is Google and Wikipedia...

From stackoverflow

• I think the only way to learn programming is to program. So do your best and don't be offended by criticism.

  Reading is paramount too, but unless you have the practical experience, bad advice from written material can easily mislead you.

• I have been on that path, its not so easy but makes you tough. You will need to read up a lot, analyze work done by your seniors, it tells how they think. Keep an open eye, your mentor will not always be right. Lack of mentoring can mean you need to do it all yourself. You can also see mentors in people like Martin Fowler, Scott Hanselman and get ideas from the community. Keep learning, keep coding, keep self analyzing.

  Good Luck!!

• My #1 tip is that, if I were your team leader, I'd want you to ask me questions, even if I am busy (and, I'm always 'busy'). It's much easier for me, if you tell me what you information you lack (by asking me), instead of expecting me to:

  • Guess what it is that you don't know
  • Supervise you to check that you haven't gotten stuck or off-track on anything

  My #2 tip is, understand what the quality-control measures are: developer testing? Code inspections? Automated unit tests? Integration tests by a separate QA, working from functional specs which you write? Because, in the end, what matters is that your work has sufficient quality; and assuring quality is the team effort, of mutual interest. So discuss QA with people (what kind of testing, how much testing, can we do code reviews, etc.).

  My #3 tip is that code reviews are a good (perhaps the best) way to do knowledge transfer as well as QA: they're the opportunity for more experienced people to, not only verify that you're not checking in bugs, but to see where you have any weaknesses or anything they might have done differently, and tell you.

  jandersson : So you're saying it's too much to ask from a team leader to supervise team members to assure work is on track and progress in made?

  ChrisW : It depends on the team leader's responsibilities, which IME are to do other things as well as supervising: helping/mentoring junior developers is only a [small] part of the job. I'd prefer to be able to trust a person to 'interrupt' when appropriate than for me to need to continuously 'poll' them.

  AngerClown : Most people want to help you, but they are busy and working on their own tasks so they won't go out of their way to find you. You have to _ask_, which can be very hard to do for us introverted programmer types. Pick something that looks interesting in the code base, try and understand it, then schedule time with the developer who coded it to make sure you got it right. Offer to help them with something. Repeat and start making small contributions where you can. Log all your time doing this so you can show your manager occasionally (schedule a review meeting yourself, don't wait for your boss).

• Assuming you are an experienced coder already (not neccesarily for team programming), all you need to do is check out other programs that have been made for your company, and try to adopt a close style / format / layout / approach so that you won't be breaking standards. The rest is trial and error.

  edit: style & format include how syntactic sugar is handled, as well.

• If there aren't people there who can mentor you right now, you would do well to read some classic books for programmers, as discussed in a previous question:
  Stack overflow question about influential programming books

  Code Complete is very good, and there are others on the list worth checking out.

  Regarding your question of "What I'm concerned about is how will this lack of mentoring affect me in the future?" I think that it's highly unlikely that you will be irreparably damaged by having to find your own way right now. More likely, the experience will make you stronger. To be sure you lose something by not having experienced people to guide you directly, but consider that anyone that could have been supervising you would have their own biases. And therefore you would have to think yourself and teach yourself even if you did have many mentors available.

• I started from scratch some 25 years ago. Obviously I was able to cope somehow, but I really feel my growth was stymied by the lack of constructive input from peers.

  Some of the junior folk at my last employer had it pretty good. They were surrounded by 4 very experienced developers with various backgrounds. We more senior types encouraged them to find answers own their own (this site makes that much easier) but were always around to help before frustration set in or serious mistakes were made.

  In your position, if you cannot get the support you need at work, involving yourself in communities such as found here or on sites more related to your work is probably your best bet. Everyone needs peers to help them through tough spots (or brain farts).

  Personally, I need people to bounce ideas off of... even if they dont respond to anything I say. The act of saying things to somebody out loud often helps me solve issues.

  ChrisW : There's a story (I forget where I read it, unfortunately) of a university computer lab, where the Teaching Assistants kept a plush toy on a chair outside their office. If you had a problem that you wanted help with, you had to explain it to the plush toy, before you would then go and ask a T.A.

  Sailing Judo : lol, too funny! Maybe thats what I should do at work... place a small Dilbert (or better yet, Dogbert) doll outside my cube for that purpose.

• I agree to "unanswered" most of the people learn by themselves (atleast who are passionate about programming). No one will teach you how to program in an organization. They will train you about projects.

  1. Learn online
  2. Watch video tutorials (ex: www.asp.net, www.learnvisualstudio.net)
  3. Participate in unofficial tech camps or meets (ex: barcamps, MS user groups etc)
  4. Try to get a certification by going for a training : You have 2 advantage you will get to meet new people and learn new things
  5. Subscribe to good blogs (http://stackoverflow.com/questions/78955/what-are-the-best-programming-and-development-related-blogs)
  6. Listen to good podcasts
  7. Participate in tech forums and if interested start a new blog and record your learnings
  8. And most importantly Love what you do.

  Edit: 9. If you don't know. Ask!!!!! 10. Dont Assume (ASSUME .. You are just making an d ASS out of U and ME)

  This is how I learned. I am 23 now and work as a senior developer. I started @ the age of 19. All the best :)

  Shyju : Really Great Buddy

• Mentoring is the exception rather then the rule, I'm afraid.

  Not having a mentor will probably mean you'll get to make many of the same mistakes others have made and waste a lot of time doing so.

  However, look at it this way, you'll truly understand why some things work and others don't, perhaps more so then if someone just tells you why something is incorrect.

• start reading

  Refactoring: Improving the Design of Existing Code

  Code Complete

• I learned and continue to learn most by reading code. If that's too boring for you, pick your favourite (small!) open source project and recreate it in a different language. Stay as close to the original behavior as possible. That way you have to go into the open source project's code and read how they solved it.

  Don't worry too much about which project to use and if it will teach you bad coding style. Because here is the kicker: After a while you will know if it's bad or good code you are reading. You'll get a feeling for it.

  Move on to the next project and reiterate.

• I've been in a similar position as an intern. One thing I found helpful was the fact that the company I interned at had a corporate subscription to Safari. It allowed me to get up to speed on new technologies with out needing to constantly Google everything. You can find more info about it at http://safaribooksonline.com I would check to see if your company has a subscription.

• Make a conscious effort to form ego-less opinions. Don't be afraid to express them, but more importantly, don't be afraid to let the opinions of others inform your own.

  Make a lot of mistakes. When in doubt, error on the side of 1) your customers and 2) the programmers who will have to comprehend and modify your code later.

  Build things, always build things.

• If you are reading Stack Overflow, you are doing more than most software developers. I read a survey that the average software developers reads less than 1 software-related book per year!

  As other posters have said: read, read, read! Read blogs, books, and your co-workers' code.

  The technical books I found most enlightening include:

  • Code Complete: A Practical Handbook of Software Construction

  • Domain-Driven Design: Tackling Complexity in the Heart of Software (This book is very dense, but it blew my mind.)

  • Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity

  • Design Patterns: Elements of Reusable Object-Oriented Software

  • C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

  • Refactoring: Improving the Design of Existing Code

  • About Face 3: The Essentials of Interaction Design

  • Extreme Programming Explained: Embrace Change

  • Fred Brook's Mythical Man-Month

  • Writing Secure Code (Yes, this book is from Microsoft Press and uses Windows for many examples, but the fundamentals are important and universal.)

  • Extra Credit: Structure and Interpretation of Computer Programs (SICP)

  talonx : I would add to the list - Prefactoring, The Art of Agile Development, The Productive Programmer, Algorithms (Cormen/Rivest et al)

• The fact that you have no mentor may not be that bad. You only really need mentorship to help you with the project source code, internal libraries and mechanisms.

  As far as the general technology knowledge goes, you can pick up the missing bits and pieces on your own. A good mentor could be of great help. Just as a bad mentor could ruin you skills by teaching you to do things in the wrong way.

  For example, right now I myself could mentor our senior developer on a few things in C#/.NET and general software architecture.

  Maybe it is your destiny to become the CTO in your company? ;)

• My first job I was a lone programmer in a non-software company, when I finally did work with others, they were peers at best. It was 4 years before I worked with anybody with more experience than myself.

  The pros to working by myself were:

  • I had total control over my projects
  • I learned quickly to write more robust code, since I maintained everything I wrote.
  • Communication was minimized to me and the business owner, which increased efficiency.

  The cons were:

  • My inexperience caused a lot of mistakes including; technology choice, design decisions, and not knowing / not wanting to tell my boss 'that's not possible'.
  • If you stop proactively expanding your technology exposure, it's easy to go stale real quick.
  • When you're stuck you're screwed.
  • I could only guess if I was doing good work or not

  In retrospect, if I could go back and do it again, the one thing I'd ask my boss to do is find a senior developer / architect who could review my decisions & code on a regular basis and provide honest objective feedback. This could have seriously accelerated my learning curve, and my company would have saved time/money, and would have easily paid for itself!

  In my case it would have been an external consultant, I don't know if your company would have somebody who could do this in house or not.

  Good luck.

  PS-I do feel privileged to have gotten the experience I did. I'm glad I didn't go straight into consulting.

• I'd say that if you're lucky to be spoon-fed with mentoring, you'd be better off than most people. What ChrisW says is all good but many people don't even have a boss that is even able to answer your questions. What about all the entrepreneurs that start out single handedly? Everyone else being too busy is more the rule than the exception. It's a huge boost having a mentor, not something you should take for granted.

• I think you can become a good programmer without a mentor. But having good people above you is really important for you in your professional career. If your boss is a good manager you will grow as a professional in a more general sense, and she can help you to realize your long-term goals. If he is incompetent it can really hurt your chances. To some extent that is true for your other colleagues as well.

  Having great people around you is what really matters.

• When I got started into writing code for a living, my first few projects I worked on were pretty rough. No one wanted to help because we were busy, and no one had time to look at what I was doing.

  I started simply by asking the best (most talented and respected) guy in the group how he did things. If he had an example code or a "standard" he followed. By seeing and letting him set this standard, it gave him the feeling like he was molding me, almost like he was my "boss" even though he wasn't. He appreciated this, and I appreciated this as well. With this, I was able to learn from my team. After that, I'd try something new, and let the other team members pick it apart. Sometimes it was brutal, but I learned fast.

  Not sure if that's really where you want to go for an answer, but it's one guys humble story.

• My boss once told me, if you're not breaking anything, then you're not working.

• It's funny how you've titled this 'Junior' programmers. Does that mean that somewhere along the lines people slowly move up in the ranks and become seniors, experts, gurus? And who defines who gets which title?

  I've been in the Army for over 5 years now, and although I'm not sure who voiced it, I was once told a great piece of knowledge that I've kept true to.

  There are only **two mistakes** you can make in life...
  1. The mistake that costs you your life.
  2. The mistake that costs the life of someone else.
  

  In adherence to this... Nothing is a mistake in programming.

  It either works or doesn't.

  • If it doesn't work, fix it.
  • If it does work but not as planned, refine it
  • If it works, leave it!

  I started my life pulling apart an Apple 2E and progressed from there to a 386 with Windows 3.11 and then to a Pentium with Windows 95 and onward. My father hated me because I always found a way to break the computer or change it to something different.

  Today at 23, I own my own business where I manage over 200 corporate web sites with 40 ongoing clients who all turn to me for advice on anything related to computers and website design. I don't have a degree or any qualification in computing but I write extensive PHP/XHTML/CSS enabled websites using Joomla.

  I learnt everything I've needed to get this far from the internet and just playing around with code. I run two staging servers at home based on CentOS 5.2 which mirror my hosting server. On these staging servers I 'break' my code in, work out all the bugs then once I'm happy I replicate the site to the live servers.

  I wouldn't call myself an expert or a guru, I just know what I'm doing. I don't have a piece of paper attaining to what is in my head but I've got numerous examples of my work and most of it is displayed for free.

  As said above, you're in the right place to learn, as you've identified the hardest thing is to ask.

  Use Google, blogs, wiki's and any text book available, use the experience of people who have tried to do the same thing and you will slowly pick things up. There are no text-books called 'Programming in 7 days', there's no easy way to pick it up you've just got to experiment.

  JUST REMEMBER TO ALWAYS KEEP A GOOD BACKUP

  All the best

• I was lucky enough to start my IT career working in a small shop as the sole junior developer under 4 extremely experienced developers from around the globe. Together they had more than 60 years combined programming experience and a lot of what they said in the beginning was honestly over my head.

  I began working with them as a fresh graduate with only a 2 year Associates degree. So, basically, I thought I knew a few things. What I found out pretty much right away on day 1 was I knew pretty much nothing.

  One of the senior programmers became both my supervisor and a true mentor. His initial conversation with me involved what he expected of me and what I could expect from him. He was very clear that I could come to him with anything at anytime and we would work through it together. He also told me while he would always be available if I had questions, part of the career of a software developer is solving problems and that I should try to answer my own questions first by other means. His point was simple, it was part of my job to research and expand my own skills. As I spent more and more time researching improved methods and alternate solution possibilities, my mentor told me researching is a requirement but at some point, I had to decide on a solution. With the amount of information available now, it is too easy to be in a constant state of looking for alternative answers. Be careful not to get into the state of over-thinking a problem, you may run across some new way of doing something, but you also risk coming across as indecisive.

  While I gained an immense amount of knowledge from him, and the other senior developers, I learned how to learn in a professional on-going nature, not as a college student (and there is a huge difference in those two methods, at least it for me). I would not have improved as quickly without a mentor but I was in a position where I either had to improve or it would have been a short-lived career path.

  So I will just re-iterate the overwhelming response of those before me in this thread. Read, read, read. I think in the first year of my professional programming career I read more white-papers, books, and other articles than my entire Associate Degree program required.

  Other than just reading, places like SO have always been helpful to me over the years. I would also recommend Dr. Dobbs as a potential source -- http://www.ddj.com/

  You already are ahead of the curve by knowing you need some feedback, absorb all the information you can find; become an information sponge. Good luck

• My suggestion would be to ask your manager or team lead about the process for some of the rather basic things you are likely to be doing:

  1. Version Control System - Is there a specific way to use this software where I work? What conventions exist that are worth noting somewhere so my code doesn't stick out like a sore thumb? Can a check-in/commit break the build and this is OK, or does breaking the build be one of the greatest sins one can commit where one works?

  2. Promotion of code - If you have at least a couple of environments, development and production though there can be a few others possibly like a QA and staging for a couple of other examples, what is the process for pushing code into production? Is it cowboy style where whoever wants to push code into production can do so without any warning or is there a process for this?

  3. Coding conventions - Is there an agreed convention in naming variables and methods, e.g. camelCase or using underscores or hyphens? Are there code reviews to check my code by someone else? Are there tests to be bundled with my code so that anyone wanting to review the tests can do so in an easy manner? Does the team I'm on have a standards and practices meeting to share what conventions some may be using?

  If you are working with other developers this may make things a ton better so that you know how some of the other guys are working and blend in in a desirable way. Some of these questions may be met with a, "Do we do that here?" type of questioning though that should be OK as then you can help build the process which is an excellent way to develop that skill of helping future developers as well as yourself and other junior programmers around you.