The company I work for has ~25 employees.

Today we finally got the entire development environment up and running on my comp., and the senior engineer walked me through (from a user's perspective) the final product of the software we produce. It was really interesting and I learned a ton...but the catch is that he is going to be out the next 2 days and I have zero clue as to who I should "report to" in place of him.

I guess I will just look through some old tickets/bugs and try to figure one out?

Also, would it be inappropriate if I asked a developer sitting next to me if I could just look over her shoulder for a while?

Oh yeah forgot this, that should def. happen within the first 5 days.

Both very good ideas imo. You could also combine the two and tell her you'll try to fix bug X and if she could look at your code etc.

Picking a random bug and just starting on it just seems weird to me. This seems like a case where your initiative should be a 5 minute conversation asking for ideas of things to work on. If that doesn't go well, I guess pick a few bugs and talk to someone about which ones they'd like fixed.

I've also never been at a place (or heard good things about) a company that would leave someone new alone for a few days hoping they'd pick something up to do. That just feels like setting someone up for failure.

Yeah it's definitely a confusing situation, but it may just be me. It actually seems like a great company...everyone there is extremely nice and friendly, and everyone I've talked to about anything technical seems super competent. All the employees seem happy and well taken care of, etc.

Considering the guy I've been "reporting" to won't be there tomorrow or Friday...would you suggest I just approach another developer and ask them for something to do/if I can help/etc? I really have no clue about the hierarchy/chain of command.

Yeah, I don't mean to be too harsh on them. Sometimes things are more busy/hectic/disorganized than you'd like and you have to do sub optimal things.

Edit: If it were me I'd have asked my manager when they told me they'd be away. But if that ship's sailed then maybe ask your neighbour if there's something they find annoying or a bug that they'd like fixed that you can work on?

Well as we finished up the stuff he was showing me today, he said something like "well, this should keep you occupied the next two days, ya know, just keep clicking around and exploring and stuff"

Yes. That's the one. He's my hero, unless you're a future employer who's found their way here, in which case, I'm obviously joking.

i pretty much share shabby's view on what's going on here: this department sounds like it has a number of immature practices (no onboarding plan, set up your dev environment by hand, configure the database via some backups on some shared drive).

however i also think shabby is underestimating how many shops in the universe are just like this.

Oh, I know they're common. I was just saying all of those places were no good (which I know is an exaggeration).

oh and to give derada some actionable advice:

i think expectations of you are extremely low, so showing up sober every day is a great start.

as the new guy, you have two missions:

- find ways to make yourself useful. solving little annoyances is great because it usually doesn't require extensive system or domain knowledge (it's just that no one ever has time to sit down and fix it), it helps you win friends, and it lets you touch a few different areas. this last one leads into your second mission...

- reconnaissance. figure out who you want to work with and what you want to work on, in that order. everything else flows from this.

Are there any plug-ins for Chrome or Firefox that has jump keys? I'd like something where I can press say, alt-ctl and then have letters pop up on all the links and text boxes. I press said letter and I am sent to that link or box.

Agree with this. Small shops are great for learning and getting recognized for your work, but big companies have established practices and training for new devs (esp junior devs).

You will be mostly useless for the first 3-6 months as a junior dev. The objective is to do your job well. Exceptional performance comes later. Fix bugs in a timely manner. Leave the code in better condition after fixing things. Communicate well with others. Fit in with company culture.

Also I recommend http://www.amazon.com/New-Programmer...ammer+survival

Useless for 3-6 months? That's a really long time. Is that assuming like no familiarity with the tools being used or something?

If I hired somebody who was useless 6 months I'd be kicking myself.

Yeah, useless for 3-6 months seems ridiculous. Whether we're talking about interns/new grads/senior people we expect them to be useful in days or at most a week or two.

I'm not saying they'll be super productive, and they'll still be a drag on other people in terms of needing help/guidance, but 3-6 months is horrible.

Shameless plug, but I ported some of the Vimium functionality to Safari in the form of Vimari. The features are very limited, but the jump keys in particular work very well.

https://github.com/guyht/vimari

ugh I'm addicted to codewars for some reason.

That is a super neat site

yeah IDK problem solving is fun but the vast majority of these best solutions are "oh just use Array.prototype.obscure".

there are many

Vimium, press 'f' and all links/boxes are labelled with keypressesf

I suppose useless was the wrong word choice. I meant reaching productivity level deserving of the salary. 3-6 months is entirely reasonable in my experience. When I started here I had to learn a ton of domain knowledge (manufacturing/supply chain).

The companies I'm referencing usually don't have "managers". It's mostly a pool of devs and/or bizdev folks+a ceo/founders who are often not around all that much because they are travelling all over the place.
You typically get a dev assigned to keep an eye on you but it's pretty much always
1) Short grace period of getting everything up and running, figuring out how the product(s) work(s) from a customer and codebase POV
2) Talking to people, figuring out what you should work on (there may be some task set aside for you but often there isn't)
3) Write some (any) code and see how it fits in
4) Start to grab work from the agile grabbag (or PM tool or whathaveyou)

-> Self-sufficient from the getgo.

First one I tried...
SystemStackError: stack level too deep

Ruuuuuuuuuby (damn imperative languages...ok I'll iterate already...or well just resort to math I suppose)

or JavaScript

I think that site could eat Codecademy's lunch if they bothered to make a beginner tutorial. It's all the good parts except that if you don't already know how to do something your only real recourse is Google.

Speaking of Ruby, after trying to actually use a function as a value I was surprised at how complicated it turned out to be. Right now I'm tempted to say that I don't think Ruby has first-class functions, and that this is a vacuous truth because Ruby doesn't have functions (rather, it has four* (!) constructs that behave kind of like functions). I'm especially confused that `lambda` exists at all given that it doesn't appear to interact with any of the Lispy "higher-order functions" (`map`, etc) in any way.

FWIW I know that this isn't a practical problem most of the time, but this isn't the kind of thing I'd expect from a language with Ruby's reputation...

* By my count: methods, procs, blocks, and lambdas (which may or may not count since their type is a proc according to irb but apparently lambda procs behave differently from procs created by Proc.new. And I might make a distinction between an object created with `method` and one created with `def`, I guess, so five?