9

I came across this excellent post:

I recently started my first "grown-up" job as a software developer. As exciting as it is to get paid for doing what I love, I can't help but wonder if I'm expecting waaaay too from a company.

My main issue is that I know virtually nothing about the (very large) application I'm maintaining, or even the business domain...

I was really expecting that someone would sit down with me and give me a nice demo of the ins and outs of the application and the business, but no one seems to be willing or able to do that.

The above post led me to a question that I have:

As a new employee hired on as a developer, what should I expect when joining a company as a developer, in terms of training regarding the company's business domain and business practices?

Improve this question
  • 4
    How is this in any way an answerable question? What do you mean by "good?" What do you mean by "veteran?" – enderland Sep 14 '12 at 19:00
  • 3
    I don't think this is a constructive question. I expect answers from both sides will be argued, all backed up by personal experience (or just argued). – yoozer8 Sep 14 '12 at 19:04
  • 3
    This is very common problem. It obviously doesn't have "one" simple answer but this is a case where even opposing answers could provide helpful insights. – Angelo Sep 14 '12 at 19:08
  • 3
    @JimG. I asked a question on meta – scaaahu Sep 15 '12 at 12:16
  • 1
    Documentation. Both non-technical (employee handbook) and technical (code practices, project-specific documentation and specifications, etc) is very important. – SaltySub2 Aug 20 '18 at 9:09
8

In a perfect world that does not exist, I would hope that all companies teach:

  • How to get what you need to do your job - the tools you need, how to use anything that is specialized in the company, any company specific processes or practices. Basically picking up on the technical particulars that weren't covered in the average training for the field (for example, one assumes a software developer can write code... but if the language is proprietary, there should be docs or a training course).

  • What the company is doing/making - some background info on the product or the service or whatever it is that makes money for the company. In cases of consulting, it may just be customer service type training, or information about how billing works.

  • How to be successful in the culture - In this bucket I put everything from painfully boring HR classes on sexual harassment, work ethics, and security training, as well as possibly more useful stuff like a quick doc on "how/when to call a meeting" as well as the conscious effort to get new employees into the "vibe" that can't be formally trained, but has to be influenced.

But it will vary wildly by company how formal or well-defined any of this is. A small company may just say - "computer's overe, watercooler is here, we'll send you a demo the next time we do one." A big company may have 6 months of "onboarding" to get a new employee up to speed.

How a company does this will say alot about the company and what they consider important. For example, software firms that create high-end, life-critical systems tend to really emphasize testing and quality assurance - there may be weeks of formal training, and you may be invited to peer reviews and given feedback on your first few projects - all focused on rigorous testing and QA. Another company may be a "fend for yourself" style company, where nothing gets checked over, but when your code needs fixing, you are on the hook for it. Different industries tend to have a different vibe.

Improve this answer
  • +1: Great answer. And I'd love to know if, for those industries where nothing gets checked over, if there's any hope of improvement. OTOH, maybe you've spelled it out exactly as it is and how it always will be. – Jim G. Sep 17 '12 at 13:47
  • @Jim G - life is change. I'd say that this is one of the pain points in "growing pains" - past a certain point, your company probably can't thrive without some structure and double-checking... and the implementation of such structure is one of the things you hear people complain about when a group goes from 5 to 15, or 15 to 50. Failure to grow without also growing process & training usually results in catastrope, aka "expensive learning experiences". :) – bethlakshmi Sep 17 '12 at 14:11
6

In a new job I believe one should expect to be shown the ropes. What that means, however, is different in each company and depends on the position itself and the experience the new comer has as well.

The best introductions to a new job would indeed include all that the asker you have quoted expected, but as experience shows, many employers are not the best at many things, including inductions.

Many companies do not have induction plans at all. Some that do are the ones conducted by HR regarding company policies and procedures and a work related induction never happens.

In many ways, the induction is up to the manager of the new person - and managers certainly vary in their approaches and care for employees...

Improve this answer
  • 1
    @JimG. - Answering a question and voting to close are two different things. I voted to close (after giving an answer), because of the reasons listed in the close notice. If you are looking for points of view, Stack Exchange sites, including this one are not the right place to ask... – Oded Sep 15 '12 at 6:50
  • 2
    "Many companies do not have induction plans at all." That. As a general rule, the smaller the company the less likely there is to be any sort of formal induction, let alone training. A small startup will generally expect you to be able to work and get yourself up to speed independently. Even larger companies aren't above throwing new hires in the deep end on a large and complex legacy codebase that nobody in the company really knows anything about anymore. – aroth Sep 17 '12 at 4:18
4

In a perfect world, you'll be walked through the application and the codebase, and given any supplementary materials you might need in order to maintain the system.

Reality, however, is normally much less idyllic. After all, if there are people to do all that, then they really don't need you all that much. In practice, you should expect a basic introduction to the application, and possibly some old notes that were made on it originally. Often, if you dig around on the company's network enough, you'll find the original design specs of the application, but that's a bit outside of the scope of this question.

Now, this might all seem to paint a very bleak picture, the fact that you will most likely not be given very much direction or training for maintaining a specific application. However, you can mitigate or even eliminate the issue if you are a bit proactive. As long as you know the language used to make the program, you should be able to find plenty of other programs online, written in that same language. Download them, and learn them. Step through the code, line-by-line, and basically read it. You want to be able to read it like a story, and in this way you'll be able to teach yourself the application in the future, when you get to it.

The most important lesson you can ever learn, is how to learn. Once you have that down, have fun!

Improve this answer
  • "Walked through the codebase". In an ideal world... :) Usually it's "download the repository, google anything you don't understand" :) – SaltySub2 Aug 20 '18 at 9:07
0

Possibly, yes. The question I'd have is how mature are the people and processes at the company for handling bringing in new hires? Many places would expect the new hire to "jump in" and learn the stuff on their own without supervision, I'd expect. I'd suspect 80-90% of job descriptions I see will have, "work well with minimal supervision," which is part of what is being asked here is that supervision to bring someone up to speed.

If the company is mature then there should be a contact to assist if there is a question or desire to know more than what reading the documentation, tests, and source code has. However, there is something to be said for what work is being done and what would be useful as if the main application has tens of thousands of lines of code then an overview may not be useful if one is fixing minor functional bugs that don't correspond with an overall tone of the code.

Something to consider is how well is he phrasing this request. Is he conveying a sense of entitlement that everyone is to bend over backwards to spoon feed him? Is he being specific enough in the request for assistance that it can be met? I suspect this is the type of communication expectation that will happen repeatedly if he isn't prepared to be accurate and precise in these requests.

"Baptism by fire" would be a typical situation I'd expect as developers are expected to know how to learn what is needed and use that to solve a problem and move forward. Figuring things out on one's own is part of this process that is rather natural, at least to my mind and in most of the cases I've had in my 13 years of work.

Improve this answer
  • "'Baptism by fire' would be a typical situation I'd expect as developers are expected to know how to learn what is needed and use that to solve a problem and move forward." ...This methodology is increasingly prevalent and troublesome. That's not a handover, training, or any kind of reasonable approach. But as you indicate it all depends on the maturity of the company. Sometimes as long as there is a developer that can sit down with you at various points to explain some code, walk through some documentation, items, caveats, etc, that's a minimum first start. – SaltySub2 Aug 20 '18 at 9:08

You must log in to answer this question.

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