Anaphase wrote: ↑Sat May 21, 2022 9:03 pm
What are exactly the realities of software dev anyway? I live in the Bay Area so pretty much everyone that isn't a service sector serf like me is in tech, but the people that I have met who were engineers are one point are always pretty vague about what the job is like.
My impressions are below - excessively long, but to paraphrase Twain, I didn't have time to make it short. Also, it's all based on my experience from 1979 to 2003, but I would bet a whole lot of it still applies.
As an entry-level developer, you may or may not be writing brand-new code. If you are, that'll probably occupy most of your time, and most of your interactions will be with other software engineers. If you aren't writing brand-new code, you'll probably be adding features and fixing bugs in code that others have already written. Bug fixing (aka maintenance) really runs the gamut in difficulty, but it seems like almost every software project has at least one crazily convoluted module, written by some departed person, that everyone dreads digging into, and naturally "let's assign it to the new person" is a popular choice. Anyway, when you're fixing bugs you typically need to interface with non-developers, particularly the test group (there'd better be one!) and tech support.
In any event, you'll spend time on some things that you may not have encountered in coursework; for example, source control, which is the process for ensuring that changes are made in an orderly manner and that the current build, the latest known good build, every previously released build, etc. can always be recreated. Source control may or may not take up a lot of your time, but the processes have to be followed to the letter in order to avoid embarrassing miscues like clobbering someone else's source code changes.
Depending on the size and structure of the organization, you may have more than one boss. A classic arrangement is that you officially report to the manager of a functional group (like, say, applications programming), but at any given time you take your day-to-day direction from the project leader for whatever app or system you're working on. If those people are good at their jobs they'll try to avoid giving you conflicting assignments, but shit happens, and it's really important to speak up - preferably in a tactful and objective way - when it does.
Most likely, no one will be terribly concerned about what time you show up and what time you leave, unless there's some critical meeting. (Hopefully you won't be working for some maniac who'll call a 1 a.m. all-hands!) You may not even be expected to show up in person most days. What will matter, a lot, is your productivity - especially whether you get things done on time - and the quality of what you produce. Speaking of quality, if you're working in a "mature" organization, there may be code reviews; otherwise your work will probably be judged after the fact by how many bugs it has and, eventually, how easy it is for others to understand and modify.
You'll probably be asked to estimate how long your tasks will take, and there's an art to that. If your first reaction is "5 minutes", because you can see in your mind's eye exactly what code you'll need to write, and you know you can type it in 5 minutes, remember you have to also allow time to check out the source file(s) from the source control system, make your edits (including comments!), get it to compile, do a build, test it, debug it (you'll almost always have to fix or rethink something), check your changes back into the source control system (and resolve any conflicts that may have arisen if another developer is working on the same code), and possibly write up test cases for the software testing group. So you can't let bravado enter into your time estimates. On the other hand, there will usually be pressure to release software by some predetermined date, so it's rarely possible to make your life cushy by being generous with your time estimates.
Speaking of which, unless you have the incredibly good fortune of working in an environment with no deadlines, it will almost inevitably arise that you provide a thoughtful and well-reasoned estimate that a task will take, say, two weeks, and then your boss (or one of your bosses) comes back and says "we need it in one week". The best response, provided you understand the task really well and strongly believe in your original estimate, is to explain what compromises will have to be made in order to complete the task in the shorter time frame: perhaps one or more features can be left out, perhaps a simpler algorithm that sacrifices some performance can be used, perhaps you can work extra hours... Whoa, what? Yes, if you're a salaried employee, which is likely, you may be expected to just suck it up and put in the time. If you're lucky, compensatory time off ("comp time") may be available, but make sure you know the rules in that case. Of course, beating time estimates can have benefits down the road, such as being seen as a good team player, a highly productive developer, etc., which can translate to bigger raises and faster advancement. If the project is critically important, it may even help boost the success of the company and be one of those rising tides that float all boats. And some people feel amply rewarded simply by being part of a team that gives it everything they've got to build something totally cool.
Oh, and you'll receive more and more email as time goes by, and will have to defend against its tendency to soak up more and more of your time. You'll need to keep your messages short and pithy, the sad reality being that even in a professional setting most people simply won't read more than one paragraph lorem ipsum dolor lorem ipsum dolor lorem ipsum dolor lorem ipsum dolor
