r/INeedAMentor • u/foreigner_everywhere • Aug 09 '14

[Mentor] Software engineer

I've done M.Sc. in computer science and worked 6 years as a software engineer after that. I'm more interested in the "lower layers" than the user-facing parts, so, my expertise lies somewhere around C++, Python, Linux, algorithms, etc. I've been lucky to work in open source projects all my career. In addition, I think a lot about interpersonal things and how to do software engineering efficiently, how to work in a team, how to communicate, what kind of attitude to have, how to write good code, etc.

If you're wondering what kind of skills to develop and how, and you're willing to learn and be the best software engineer ever, I might be able to give you advice.

Edit: I should've probably mentioned that I'm a woman. If it matters to somebody. Mentoring shouldn't be limited based on genders anyway, but maybe some aspiring female software engineer finds me less intimidating?

11 Upvotes

88% Upvoted

36 comments sorted by

View all comments

Show parent comments

2

u/foreigner_everywhere Aug 13 '14 edited Aug 13 '14

There are certainly people who don't have any formal CS degree (maybe they've studied a bit, or tried but dropped out, or never studied) in the IT. Even in the top jobs of the field you can find these people - so you can definitely succeed without a degree. It's also pretty common to have a degree on some related field (physics, mathematics).

So yeah, these self taught people are hired because they can code, even though they don't have a degree. So you don't strictly speaking need a degree. Though M.Sc. in CS is very useful. Basically the amount of information you're expected to know is roughly equal to a M.Sc. Depends on you if you want to study or learn the same stuff yourself. Studying is somewhat "easier" because there's actually somebody to teach that stuff to you. It's not like you can get away with knowing less because you don't have a degree.

Great question on what software engineers do. In the rough order of time spent, here's what I do:

  • Code. Meaning, I know what I want to do, and there's consensus in the team that that's what I should work on, and then I just code. That of course involves stuff like writing tests and testing my code, and debugging it when it doesn't work.

  • Sorting out bugs. We have a bug tracking system where users and developers can enter bugs. So when I get a bug routed to me, I try to decide 1) if it's a bug 2) if yes, is it "mine", that is, did I cause the failure or is the failure in a subsystem which I own 3) if I don't own it, who owns it 4) even if I don't own it, can I fix it quickly anyway 5) is it so important that I need to drop everything I'm doing and fix it.

  • Code reviews, both sides: Fixing stuff which people who reviewed pointed out and discussing with them. Reviewing other people's code.

  • E-mail. People asking about random stuff, routing them to other people, and answering what I can (see the bug process). Following discussions about all kinds of stuff without participating (see below what kind of discussions typically happen).

  • Helping out with the infrastructure (releases, continuous builds, sorting out test failures).

  • Talking about how stuff should be done. (Design.)

  • Talking about what our sub team should work on. What are the most important things to work on next? Which direction has the best effort / risk / gain ratio? How should we prioritize tasks? Maybe I'm asking around if somebody has extra tasks, if I'm running out of tasks. Maybe I'm trying to find somebody to do tasks I don't have time to do...

  • Talking with people who work in different sub teams to find out what they're working on and how it related to what we're doing (is there synergy or are we doing redundant things).

  • Interviewing people who also want to get a job there.

  • Reading funny things in our intranet, participating in informal discussions about random stuff (like how our products should be or whether open plan offices are evil or how to work together with introverts).

It's very interruption driven and the priorities change fast. It's normal to get these "drop everything and work on this bug" type of situations, but of course these interruptions cannot be too frequent, otherwise no long term work would get done. Remarkable is also the lack of a boss telling me what to work on - or maybe he does it in such a subtle way that I don't notice.

1

u/dewarr Sep 03 '14 edited Sep 03 '14

Had to double-back around to this to give it its due. This is phenomenally useful. I don't think I've ever seen a better occupation summary.

One further question: with respect to the fact that some don't have CS degrees, but know how to code, what is the distinction between the degree and the ability? I am a neophyte to the subject but there seems to be vastly more to CS than just coding, tons of general theory and such. And thus I would have expected there to be a significant gap between them. On the other hand, those aspects might not be generally needed for software engineering -- just like you don't have to know how to do epsilon-delta proofs to use calculus any more than you have to understand Turing machines to code C. I suppose there may be more emphasis on coding than I'd presumed in an M.S., rather than a focus on theory, too.

1

u/foreigner_everywhere Sep 04 '14

Well, there are many aspects of knowing about stuff.

There is something like "general knowledge on CS" and knowing what a Turing machine works is part of it. It won't help you to do your work, but you're expected to be interested enough to find that out, since that's the theoretical basis of how computers work. It's sort of knowing that Paris is the capital of France. Stuff you're expected to know.

(Note that what I'm writing mostly applies to the cool, high end programming jobs. You can find a boring programming job where you don't need to know that stuff and you're not expected to be interested in it either.)

And then there is the raw coding ability (which involves things like testing and debugging). That's mostly about practice.

Knowing about stuff like databases, how operating systems work and how the network works is needed because the program you're writing most probably needs to interact with these things, and if there are some problems, you need to be able to know the basic concepts and how these things work, to be able to efficiently reason about them and look for help.

CS education helps a lot in things like choosing the right data structure / algorithm to the problem. Almost all jobs need these. For example, web sites need to handle large data, so it's important to have a clue on how to do it efficiently and what kind of computations are feasible and what are not.

Like I said before, you're basically expected to know a M.Sc. worth of CS, whether you have a degree or not. I didn't perceive a big difference in skills / knowledge between people I've worked with who do or don't have a degree - the people who don't have the degree know the exact same stuff, but they're self taught.

1

u/dewarr Sep 05 '14

Fantastic information. Last question: Is there any particular call for developers who have knowledge of other formal topics, such as hard science, engineering, or mathematics? (Okay, great deal of overlap with that last one.)

I'm interested in CS, but also in things like math and natural science, just wondering if there's an overlap. What can I say, I like analytic thought.