What school doesn't prepare you for in your first programming job | Hacker News Reader

What school doesn't prepare you for in your first programming job

debugandrelease.blogspot.com

23 pointsbobblywobbles22 comments

> Don't expect it. IT jobs frequently work past the 40hr work week. People expect everything to be up 24/7, and that means you'll spend off-hours on support. If you aren't on support, you might find yourself spending your weekend coding that new feature that needs to be in by Monday morning.

I think this sets exactly the wrong expectation. I rarely work more than 40 hours. It's very possible to set boundaries and a good employer will let you do that. If you find yourself working through the weekend it might be time to change your planning or your employer.

Aside: Maybe I am in a bubble, but do developers still refer to their job as "IT" in some places?

This seems to be an American thing.

Most American tend to not fight for any compensation or relief from work. I'm not sure why, and as an American it's really frustrating. I would never ever work for salary ever again after not receiving overtime pay. You cannot trick me. Hourly or nothing!

I'm currently studying for a career switch to software development and I'm midway through my CS degree. I sort of expect that if companies will expect work at crazy hours then I'll be compensated for such. Is this not the case? Maybe I'm dreaming but I'm in a non-US market which has fairly strong workers rights.

I've never worked crazy hours. Never more than 50, sometimes more like 35.

But if you work on a product that the business depends directly on for it's income, you should expect on-call time. If your team has it's act together, they might have a rotation where you're pageable at all hours for one or two weeks per month.

Compensation is mostly dependent on your ability to negotiate your salary.

Even one or two weeks a month might be an exaggeration. The most on-call time I’ve had has been about one week out of every 6. As far as actually getting paged, I think it’s happened about 8 times in 5 years. This is primarily at smaller companies. YMMV at a large tech behemoth.

in a country with strong workers rights you most likely get overtime pay which makes crazy hours to expensive.

more likely you'll get reprimanded for working more than 40 hours because the company would be liable to pay you even if you did not report any overtime.

Most software development jobs in the US are salaried, and since we are seen as professionals, we are exempt from the government requirement for overtime pay, and thus most companies won't offer it (this may be different in SV, I'm not sure, I don't work there).

As such, any time a deadline gets tight, management can be tempted to ask people to work later or come in on the weekends. The risk of losing the employee is the only thing that stops them sometimes, and sometimes not even then, they're only thinking short term.

And since most of the software development world has switched to some bastardization of 'Agile' development, with 2 or 3 week iterations, deadlines can get tight as often as every two or three weeks, especially if the company is trying to make do with less employees than they should have and people have too much on their plates (pretty common after a round or two of layoffs and the best employees also leaving afterwards...currently dealing with that now, should have left a long time ago myself, I've just had too much going on in my personal life to want to go through the job process again).

I've pretty much never seen compensation offered for overtime. I have seen 'you can take a few days off afterwards' offered, but not always granted afterwards, since it was just verbal, managers suddenly get forgetful, the company is still playing catchup even after your extra work and doesn't think they can let you take time off, and/or it usually has to be done off the books so people up the chain don't see it, because the higher up executives really, really don't care about you and only see you as a number (in big corporations, at least).

when you make $20 an hour, 1.5 times pay for hours over 40 makes sense to all.

when you make $50 an hour, 1.0 multiplier seems reasonable.

at $100 an hour, 'shut up and get it working' is the cry.

No, most software development jobs are 9-5 with (usually unpaid) overtime only done on an exceptional circumstances. It's been years since I worked more than 40 hours a week.

My first position was for a company who sold goods as an ecommerce vendor. We had a small shop and found myself working between 41-42 hours a week. This did not include on-call time where I was expected to answer any problems that arose with the site. On-call time was usually minimal but when it happened, it happened at some odd times during the night.

After we were down to 4 people (we lost 2), I was routinely working 43-47 hours a week

> do developers still refer to their job as "IT" in some places?

Probably anywhere that is not a "tech company" and where the software being developed for internal use. A large fraction of developers are building custom back-office systems for insurance companies, department stores, shipping companies, engine manufacturers, etc.

Most of those developers don't read hn, know or think about functional programming or anything more modern than Java 7, etc.

I think most of us on HN are probably in the same bubble.

> do developers still refer to their job as "IT" in some places?

Yes, we do. In fact, some of our employers insist on labeling us as IT Developers specifically. I imagine that in a decade or two we'll update our titles to something like AI Developers.

You might ask, which employers? Think of the biggest, oldest, slow-moving private- and public-sector organizations that you can think of. While they might have certain divisions that are innovative, most of them are trapped in the past.

And these groups employ A LOT of individuals. More and more new developers are coming on board every day. This means that the number of IT developers could actually be growing...if that term isn't killed off first.

You might ask, which employers? Think of the biggest, oldest, slow-moving private- and public-sector organizations that you can think of.

My wife works in "IT", and she's employed at Microsoft. Who do you think keeps those internal Exchange servers up and running? :-) She actually works on the security side, 'cuz those systems don't (sadly) secure themselves.

But your point is taken, most places past a certain size that don't sell hardware or software will call it the "IT department".

The survey cited is doing something weird with its measurement. It says 44% of full time IT workers do 40 or less in a week, and another 22% do 41-49. That puts the median likely somewhere around 43h. That 54h number must be the mean and include those people that like to brag about truly crazy hours.

This matches my experience- most of the time it’s about 43h a week, sometimes it’s more, and very occasionally (once per year or less) you might as well not go home.

Its weird to me that this article only discusses the social aspects of programming in a job environment, while completely ignoring the contrast between university studies and real world technicalities of programming. I feel like the latter is a much bigger issue.

could you elaborate on that please? i think it would make an interesting contribution to this thread.

Not OP but I would guess it refers to the differences in material learned and needed between school and work. School will teach you to implement sorts of varying complexity, when your day-to-day duties at work will be things you never covered in school like spin up an AWS instance, hook it up to a user experience metrics platform, basically anything to do with version control.

What sort of CS degree doesn't cover version control?

Define "cover". Yeah, you'll have used it in one or two classes. It won't be a part of your day to day workflow unless you voluntarily make it part.

It's obviously a very broad topic, but one thing that I find at least my education hasn't covered yet is how to actually _learn_.

By far the biggest part of computer science is learning how to learn the new stuff, and forget outdated concepts.

Their way of teaching around 8 subjects in a single semester is downright laughable to me. The result is that I am not really proficient in any of these 8 subjects beyond what the syllabus covered, which was almost fully outdated and covered such little ground that I cannot really do anything in the real world with this knowledge, except give their petty little "exam".

So whats the point of teaching all these broad, frankly unrelated topics (e.g. flip flop counters) when I'm not even going to ever use them in daily life?

---

Instead, how about dedicating an entire month learning git, nothing else. FFS, I've been using it for almost everything, and still don't really understand what it is actually doing.

Surely, learning how git works will be more useful to me than just learning how a hypothetical priority queue can be implemented, no?

It's briefly mentioned in the "What you learned does not apply to work" section. But I do agree it is much more of this type of issue - I didn't want to highlight here, I might do so in a future post.

Reply on news.ycombinator.com