= 27d567bc2d48d9f40e9ccc20ea370b15)
Bugmaster comments on Open thread, Jan. 12 - Jan. 18, 2015 - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (155)
(request for guidance from software engineers)
I'm a recent grad who's spent the last six years formally studying mathematics and informally learning programming. I have experience writing code for school projects and I did a brief but very successful math-related internship that involved coding. I was a high-performing student in mathematics and I always thought I was good at coding too, especially back in high school when I did programming contests and impressive-for-my-age personal projects.
A couple months ago I decided to look for a full-time programming job and got hired fairly soon, but since then it's been a disaster. I'm at a fast-moving startup where I need to learn a whole constellation of codebase components, languages, technologies, and third-party libraries/frameworks but I'm given no dedicated time to do so. I was immediately assigned a list of bugs to fix and without context and understanding of the relevant background knowledge I frantically debug/google/ask for help until somehow I discover the subtle cause of the bug. Three times already I've received performance pressure, and things aren't necessarily looking up. Other new hires from various backgrounds seem to be doing just fine. All this despite my being a good coder and a smart person even by LW standards. I did well in the job interview.
When I was studying and working in academia, I found that the best way to be productive at something (say, graph theory research) is to gradually transition from learning background to producing output. Thoroughly learning background in an area is an investment with great returns since it gives me context and a "top-down" view that allows me to quickly answer questions, place new knowledge into an already dense semantic web, and easily gauge the difficulty of a task. I could attempt to go into more details but the core is: Based on my experience, "hitting the ground running" by prioritizing quick output and only learning background knowledge as necessary per task is inefficient and I'm bad at it.
At the moment my only strong technology skills are the understanding of the syntax and semantics of a couple of programming languages.
Am I at the wrong company? Am I in the wrong profession -- should I go back to academia, spend four years getting a PhD, and work in more mathy positions? Thanks!
I would say it's a combination of being at the wrong company, and our education system being inadequate to the task.
There are many skills that are required in order to write complex software. You need to know how to organize your code in a maintainable and comprehensible way (Design Patterns, build/package systems, abstraction layers, even simple stuff like UML). You need to know how to find bugs in one's own code as well as in code written by other people (using debuggers, reading stack traces, writing logs, applying basic deductive reasoning). When you get stuck, you need to know how to get help efficiently (reading documentation, understanding the jargon, knowing exactly which questions to ask, knowing whom to ask them to).
None of these skills are considered "sexy"; and, in fact, most scientists and mathematicians that I've worked with in the past don't even recognize them as skills at all. Their attitude usually is, "don't bother me with your bureaucratic design pattern bullshit, I wrote a 3000-line method that calculates an MDS plot and it works, what more do you want". But the problem is that, without such skills, you will never be able to create anything more than a quick one-off script that performs one specific calculation and then quits.
My advice would be as follows.
Firstly, figure out what you actually want to do. Do you want to invent algorithms for other people to implement, or do you want to write software yourself ? There's nothing wrong with either choice, but you need to consciously make the choice to begin with.
Secondly, if you do want to learn software engineering, find some people at your company who are already experienced software engineers. Ask them for a list of books or online tutorials to read (most likely, they'll recommend the Design Patterns book, so you might as well start with that). After reading (or, let's be realistic here, skimming) the books, ask them to sit down with you for a couple of hours in order to review your code -- even, and especially, the code that actually works. Listen to their input, and refactor your code according to their recommendations. When you have a bug, make sure you've tried everything you could think of, and then ask them to sit down with you and walk you through the steps of diagnosing it.
Thirdly, if there are no such people at your current company, or if they flat-out refuse to help you... then find a better company :-(