8 ms·

On Being a Junior Developer

141 points by msencenb 14y ago

cllns 14y ago
Good read! Seems like good advice. It makes sense that graduates from elite schools would be afraid of trying new things, since they're used to success and never had to deal with failure. I never thought of that.
- msencenb 14y ago
  Thanks! I think this problem is in a lot of junior devs as well (not just elite college grads). You get good at one thing and feel comfortable within that bubble, but the real growth comes from pushing yourself out of that comfort zone.
nhashem 14y ago
One other major suggestion I'd add: Practice writing. Just write whenever you can, in whatever environment, no matter how unformal. Your company wiki, your personal blog, whatever. Maturing from a "junior" engineer into a more experienced one usually means initiating suggestions, not just following them. As the OP said -- have an opinion! But your suggestions will always be limited to how well you can communicate them. And a lot of your interactions wherever you work will be with non-technical people, so the better you can frame technical situations to them, the more they will enjoy working with you and cede to your judgment. I've seen so many talented software engineers not find the professional success they deserve because they couldn't write. You will do brilliant things, and those brilliant things will make your employer money, and your ability to write will matter a lot in how much that brilliance is valued. Likewise you will make mistakes, and sometimes those mistakes will cost your employer money, and when that happens someone will be upset, and your ability to write will matter a lot in how soon they calm down. Some of the most important keystrokes in my career were not for writing lines of code, but for how I composed an email. I'm not saying your expertise in software development doesn't matter -- of course it does, and a bad software engineer that's a good writer does not make them a good software engineer. But your ability to write and communicate can be a tremendous force multiplier for your career.
- freshhawk 14y ago
  I could not agree with you more. I would also add that it's not just writing those emails or communicating but actually taking the time to understand the office politics/social dynamics of the place you are working. I've seen many talented engineers miss out on the success they deserve because they felt that their specialty being "technical" meant they didn't have to concern themselves with "the politics". Often it's partly true, and it's very tempting to those more introverted than average. Write well first, but after that they should learn to tell exactly who to write to, what tone to take and when they should write to them. It can make a truly astounding difference in your career path.
- wonnage 14y ago
  Not only is writing important for working with non-technical people, but it's a big part of interacting with your fellow engineers too. Think stuff like providing clear pull request feedback without offending the person you're reviewing. And, if you work in an office that avoids interruptions by using email/IRC, it obviously helps to be comfortable writing out your thoughts. I'll also make the (admittedly unprovable) assertion that good code is good writing. Code and sentences can say the same things in different ways - what's the one that minimizes misinterpretation while remaining concise and interesting to read? Just as you want the key points of an essay to live within the most engaging sentences, important code should look important. Style in programming is as crucial as it is subjective, and it requires you to empathize with your readers much as you would when writing anything else. So yeah, dust off that Tumblr account and use it for something other than reblogging.
- tomjen3 14y ago
  And I who entered this business because I liked to deal with computers, rather than humans. How do I avoid becoming a writer, while still being able to have a job as a software developer?
  - schmrz 14y ago
    Most of us like handling computers more than humans but it's not really that black and white. In order to get the most out of your career you will need to learn how to handle humans too. That of course doesn't answer your question. You can probably keep your job whilst having poor communication skills but that will be a (significant) limiting factor for you.
speakingofprog- 14y ago
This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built and deployed about 4 months ago, it was a week of one developers time start to finish. Ever since deployment there has been bug after bug after bug, every time they fix one bug they break something else. This is an extremely simple system that should (in my experience as a developer) not have any problems. Does this sound normal, for every deployment to have new system breaking bugs? Does this sound something like they're letting junior developers (in skill) deal with systems beyond their scope of understanding? or is it normal for systems to be breaking frequently? This is the only company I have worked for with engineering that affected my work so I'm not sure if this is unique to this company or is common place in the corporate world.
- bproctor 14y ago
  I've worked at companies where this seems to happen often and it usually comes down to two things: 1) Poor communication and/or planning as far as what the end result was supposed to be. The developer built it the way they thought it was supposed to work, they find out later that it's incorrect or the specifications for it keep changing making the developer add one hack after another to get it to do what it needs to do. They'd probably like to just rewrite the whole thing, but by now it's too late. Jr vs Sr: Sr can see this coming and does whatever he/she can do to minimize it. Doesn't necessarily mean they can stop it from though, it might be too high up the chain of command. 2) Little to no testing. The developer built it and said "done" and then it was passed on to the end user. Anything of any complexity is going to be riddled with bugs if there isn't some kind of QA process in between. Developers typically suck and QAing their own work. Jr vs Sr: Sr has more experience to see possible problems before they become problems and if no QA procedure exists, will at least try to run it by a colleague before claiming it "done".
- danenania 14y ago
  It's hard to say without all the details. It's also the kind of thing that can be hard to gauge from outside the project. It could be new developers making rookie mistakes. It could be simple incompetence. Or it could be that what sounds simple to you on the surface balloons in complexity after being forced to fully engage with the problem and all its edge cases. If it's closer to the second, it could signify more of a failure of process than a failure of engineering if engineers are being pushed to release quickly at the expense of planning, time for refactoring, qa, unit tests, etc. That "this should be easy, why's it taking so long??!" attitude can create a toxic environment if it's coming from people who don't understand the issues involved.
ericHosick 14y ago
I would fault some of the points listed, like "Embrace Unit Testing", to a failure of Software Engineering as a discipline. Mechanical Engineering, Electrical Engineering, Physics, Doctors, etc. all have bodies of knowledge. We, as an industry and discipline, have no real body of knowledge. Do Doctors have the ability to make up procedure on the operating table? Why is it, then, that we don't have standard practices, like unit testing, and help get these pushed into the educational system? Should students even be learning how to write code without unit tests? Without a backlog (if that is what industry agrees to)? Without an understanding of systems? And so on.
- indiecore 14y ago
  Software engineering as a thing is less than thirty years old, those other careers have been around for hundreds if not thousands of years, the body of knowledge will come in time.
- tjpick 14y ago
  No. They are part of the curriculum in a good SE degree. There is a SWEBOK. http://www.computer.org/portal/web/swebok http://www.computer.org/portal/web/swebok
  - ericHosick 14y ago
    I found, based on my few years of experience lecturing in IT and BIS at a large university (72,000 students), was that very little emphasis was placed on building up IT as a profession based on a body of knowledge. Really, it just isn't happening. There is a huge disconnect between best known practices, such as those you linked to, and academia.
    - deleted 14y ago
      [deleted]
civilian 14y ago
There are two (4) steps. As someone said: "There are 2 hard problems in computer science: caching, naming, and off-by-1 errors" ;)
larsberg 14y ago
The biggest one I'd recommend is "find a mentor." And I don't mean a manager (unless you're going on that path), but rather a technical leader that you can meet with once a week to month whose opinion you value and can provide you honest feedback on your work. You should plan to drive these meetings; count on them only to show up, drink coffee, and answer your questions. If it is not your most valuable hour of the week/month, you either have the wrong mentor or are handling it wrong. And if your company does not have such a mentor, you should either look to find one that does or make sure you're getting paid well. Author can also follow up with me via e-mail if they want Stanford-specific advice. There are a specific set of things that the perfect-A average and BS+MS degree in CS in 5 years crowd runs into during their first few years out of school that I'd be happy to share. It's true of every school, but we had a lot of experience with the A students from Stanford, Yale, MIT, Princeton, etc., and they all seemed to run into the same problems as their alumni forerunners.
- marblar 14y ago
  Can I ask what those issues are?
  - larsberg 14y ago
    Sure, drop me mail. I'd prefer not to chat about it on a public forum. People (myself included) get defensive about their alma mater, but in e-mail you can just ignore me if you think my gross generalizations from experience are off-base for you :-)
- ninetax 14y ago
  I agree with this. I had an internship, and the mentor really made it what it was. Even if you can only end up at a mediocre company, if you have a good mentor it will be a success.
- bobbyong 14y ago
  Great advice on technical mentor! Will start looking for one myself now.
danso 14y ago
I really, really wish TDD, or any concept of unit testing had been taught in my courses. Nothing has improved my ability to understand decoupling, orthogonality, and the importance of naming conventions than test writing. And on days when I can't muster the energy to write heavy code, I can at least write the tests that I know I'll need to pass...and the next day, that heavy code task is practically done. TDD is both a good practice and a great psychological boost.
- alinajaf 14y ago
  They taught me unit testing at university and I've been using it ever since. It has a lot of benefits. But things like decoupling, orthogonality and naming conventions are worth thinking hard about in their own right, not just in terms of the side effects of TDD. Contrary to popular belief, it's entirely possible to create an unmaintainable mess that breaks regularly and is impossible to extend with near-100% test coverage.
j_baker 14y ago
My advice: don't pay too much attention to what more senior developers tell you. senior != more_talented
- novamantis 14y ago
  This will slow you down incredibly. Instead of ignoring your seniors/peers, QUESTION their "authoritative" commands. You will learn much, MUCH more that way. It also might put them in their place if they are massive egoists. Never feed the ego.
  - j_baker 14y ago
    I would like to point out that I never suggested that one should ignore their seniors and especially not their peers. I merely suggested that seniority only buys a person so much respect. It's important not to exceed that quota.
- dbyrd 14y ago
  I'm a junior developer and I've found that the old guys lack creativity, but they make up for it with experience. The people who have been programming for 20 years have seen languages/frameworks/libraries come and go, they know what good code looks like and what's just trendy. The more you ask them why they're making decisions you think are retarded the better you'll get at programming.
rjzzleep 14y ago
am i the only one who finds the article only marginally related to "being a junior/senior/antique developer"? i would summarize it as: be smart constantly learn find people that are better than you. but then again, most "seniors" probably never did any of the aforementioned. i met an ex oxford(or cambridge) cs prof who's now doing his own startup a while back. The main thing that struck me was that how willing he was to accept advice, even though he tought one of the first cs courses in the uk.
cpeterso 14y ago
I recommend contributing to open source projects, particularly well-known ones. It is a good way to see how other people and projects work, expand your resume experience, and network with people in other companies.
- linpythio 14y ago
  That's a good idea.Open source project is good practice for programmer,especially junior.Because you can read and modify others' high quality codes.
  - cpeterso 14y ago
    For people looking for a project, Mozilla has a lot of documentation and tools to help first-time contributors. "Contributing to the Mozilla Codebase" [1] documents how to get the code and build your own Firefox. "Bugs Ahoy" [2] is a Bugzilla search engine that filters "good first bugs" based on programming language and interests. [1] https://developer.mozilla.org/en-US/docs/Introduction https://developer.mozilla.org/en-US/docs/Introduction [2] http://www.joshmatthews.net/bugsahoy/ http://www.joshmatthews.net/bugsahoy/
shanelja 14y ago
I'm currently a junior developer and will share the lessons of my experience 6 months in: - Making mistakes will kill you, when you sit at home working on your personal projects and a bug slips through, it's not so bad, you can fix them and the client (or yourself) is normally pretty cool with it. On the other hand, when it's someone elses fault, E.G. yourself, your boss will come down hard on you. That's his project, his clients and his shame, if you make mistakes in a commercial environment, it costs someone money - get in to the habit of being your own quality assurance. - Your wage is shitty. Well, mine is, anyway. You have to learn to deal with this, I could go in to detail about finding housing and the lack of respect you face when you need housing benefits, etc, or can't eat for a few days, but there's no need. Get used to having no money and always put as much as you can aside for that rainy day you think you are immortal from at the moment. - Get used to being the go to guy for all the boring work, no one wants to sit there and refactor spaghetti code or build yet another custom joomla module when they have some cool CSS3 design or some technical challenge of epic proportions to work on. - Give your boss respect, he may be friendly but he isn't one of your friends, you can joke with him but at the end of the day don't forget that this (wo)man pays your wages and evaluates your work, if you're making a lot of jokes but you have a week where your work goes wrong, the evaluation will be that you're the class clown. - Slow down at the start, when everyone goes in to a new job, we work our asses off trying to impress then slow down once we settle in, even more so for a junior in their first role, we want to prove we belong in the industry. The kicker is that this pace is difficult to maintain and once you slow down your boss will notice your apparent lack of progress. - Always be early, never be late. Your boss doesn't notice the fact that you come in early every day (by 15 minutes), what he does notice is the one day you're ten minutes late and unfortunately the hours aren't interchangeable. If you make a habit of being late, you are going to get fired, this isn't college where you could turn up to a lesson 15 minutes late and get a giggle from your peers for being that guy, this is the real world, where lateness isn't tolerated for very long. - Arrogance is bad. You aren't arrogant, but you have an opinion and you come across as it, starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client. Your boss wants to appear to be an all singing, all dancing super coder and until you have a few more years under your belt, your opinion is largely invalid. However, if something is seriously wrong, drop your boss an email or a skype or a campfire (That's a thing, right?) and explain why in the least condescending way possible, if you do this tactically and only at the right times it will look very good on you. If anyone is about to jump in to their first job as a junior or needs any advice, feel free to email me, I normally check it every couple of hours.
xiaoma 14y ago
On tip #1, how big does the chunk of other people's code need to be to teach you about the things he's talking about? I've really enjoyed reading algorithms but struggled when looking at source code for large projects on github. I often feel lost and don't really know how to dig in. Any suggestions?
- 3minus1 14y ago
  I feel the same. I always hear people say to read others code. Really? Like what?
  - alinajaf 14y ago
    It depends what you're interested in learning about. I'm a ruby/rails developer by trade so rails is a really good place to start for me. The open source libraries around it like devise, cancan, haml+sass etc are required reading if you're going to be using them regularly. I'm currently interested in C and lower level systems stuff and I've found redis to be a really readable codebase. It's not an introduction to C but provides a good example of how to manage a larger C project.
- dougk7 14y ago
  I first familiarise myself with what the project does and read the docs, especially if there's an overview of the architecture documented somewhere. Then clone the project locally and open it in an IDE like Eclipse that will allow you to quickly jump between modules and see the structure of the project. Starting from an entry point (e.g the main() function), work your way into the parts you're interested in. If there's any dependency you also want to look into, just clone it and open it as well. I also prefer reading through projects I use either as a dependency or as part of a system I'm building. For that the Apache foundation's projects is an excellent place to start. They have very good documentations and the forums are filled with discussions. e.g Apache Nutch (before the v2.0 release) - there are many talks and slides you can find on its architecture and the source code isn't hard to read. http://nutch.apache.org/ http://nutch.apache.org/ Twitter's github projects are also very good - especially when I started learning scala. One project that I read for fun, it was hard to go through but the exercise was worth it is Chromium. http://www.chromium.org/developers http://www.chromium.org/developers
scott_w 14y ago
Something I learned early on was the importance of stepping back and looking at the bigger picture. A good developer improves this over time, but it's far too easy to get yourself neck-deep in code and lose focus of what's important. As a measure, if I find myself getting stuck, what I like to do is go back to the basic level and ask "what is the purpose of this?" This may involve getting more information about the feature/bug, or just talking through different scenarios. I also look at the likelihood of a scenario occurring. Sometimes, you're spending time trying to solve something that nobody knows or cares about.
Zanyinj 14y ago
I'm also a 'Junior Developer'(around 2yr) and am currently in the phase where I have started to see the faults in the systems my seniors design. There's a module that's driving me nuts, and I'm still pondering on how to tell the senior developer(who wrote it) that it's crap, over engineered and too specific. The module works to an extent, but I can see problems up ahead if the module doesn't get fixed or an alternative is created. I already knew most of the things described, but it's always nice to refresh your memory:) In this stage of my career I'm thinking more and more about going somewhere where software engineers get paid what they are worth (And I'm beggining to realize I'm worth something). With "somewhere" I mean another country. Since mine is becoming increasingly unfriendly to live in. Any suggestions/advice on how to successfully relocate to a job in another country? US or UK come to mind, since there's no language barrier for me there.
- thisone 14y ago
  This all depends on where you're from. US is easier for Canadians, UK easier for Australians, for example. For non-commonwealth/non-EU residents, the UK has gotten very difficult since 2008 for people who are unable to get an employer sponsored visa. Even to the point of doing away with both the post-study visa and the Tier 1 general. UK salaries also can vary drastically depending on where you live (and not necessarily in tune with cost of living differences). We're also on our way out of the economic mess, so salaries are going to be depressed anyway in general as companies hire on, but use the economic mess as a reason to give lower salaries.
  - Zanyinj 14y ago
    I'm from Slovenia, EU resident.
    - thisone 14y ago
      Then the UK should be relatively easier for you, since you should be able to apply for the same jobs as a UK citizen, I think? Beyond that, I'd say google. There should be a number of forums or immigration sites offering advice for EU residents that would like to work in another EU country. (I'm American, so I consider you lucky in the visa world ;) ) Could also look at the Republic of Ireland?
unitesting24 14y ago
Love #6 & #7 - Unit Testing and Refactor. It's such an important practice and best to build the right habits from the beginning. The cost of entry is so low with free mocking frameworks. Even commercial vendors like Typemock got into it with their Basic (http://typemock.com/isolator-product-page http://typemock.com/isolator-product-page)
caw 14y ago
I am what I guess you'd consider a junior sysadmin. I graduated in May of 2011. While it's not being a developer, all of the points stand. Read other code - still very important in admining. Other people write scripts, and there's a wide variety of Perl that's been written. Understand what's good and bad. 2-5 are all true. I just want to reiterate how important it is to ask questions (#4). When you start a junior position, spend time getting to know people. Set up one on one meetings with other people to get to know them and find out what they do. It's important going forward with a cohesive team. From the training side of it, if you're not asking questions I can't be sure that you understand what I'm saying. Unit testing doesn't really apply to sysadmin that much, but basically have a plan to test if something works as you're going along. If you're making 4 major updates to interdependent systems, how can you tell which of the 4 systems broke the service for the user? I ran into that recently. We had a problem that stumped 4 technical experts and two vendors for over 8 hours, when it was a relatively simple fix (once they figured out what the fix was). Systems get more complex as you add things to them, so be sure to test the individual moving parts. Refactoring is still always allowed. I feel as though you can extend this to procedures and processes. Where ever you go, there's always some "legacy" that builds up. If you ever receive the answer "That's just the way it's done" you should absolutely look into refactoring that. Odds are the decisions made back then aren't as relevant, because the base assumptions have changed. That's a major area you can show initiative on and start flexing your wings as your own person.
hawleyal 14y ago
Pfft. On being a developer FTFY
rburhum 14y ago
Matt was the smartest freelancer I ever hired
Tashtego 14y ago
I would add "practice what you preach" to this. Everyone hates the junior developer who says "ugh, this code sucks, it doesn't even have tests." Everyone loves the junior developer who says "ugh, that code didn't even have tests, so I found a seam and added some tests for the new method I added, here's how to run them."

141 points by msencenb 14y ago

cllns 14y ago

Good read! Seems like good advice. It makes sense that graduates from elite schools would be afraid of trying new things, since they're used to success and never had to deal with failure. I never thought of that.

msencenb 14y ago
Thanks! I think this problem is in a lot of junior devs as well (not just elite college grads). You get good at one thing and feel comfortable within that bubble, but the real growth comes from pushing yourself out of that comfort zone.

nhashem 14y ago

One other major suggestion I'd add: Practice writing. Just write whenever you can, in whatever environment, no matter how unformal. Your company wiki, your personal blog, whatever. Maturing from a "junior" engineer into a more experienced one usually means initiating suggestions, not just following them. As the OP said -- have an opinion! But your suggestions will always be limited to how well you can communicate them. And a lot of your interactions wherever you work will be with non-technical people, so the better you can frame technical situations to them, the more they will enjoy working with you and cede to your judgment. I've seen so many talented software engineers not find the professional success they deserve because they couldn't write. You will do brilliant things, and those brilliant things will make your employer money, and your ability to write will matter a lot in how much that brilliance is valued. Likewise you will make mistakes, and sometimes those mistakes will cost your employer money, and when that happens someone will be upset, and your ability to write will matter a lot in how soon they calm down. Some of the most important keystrokes in my career were not for writing lines of code, but for how I composed an email. I'm not saying your expertise in software development doesn't matter -- of course it does, and a bad software engineer that's a good writer does not make them a good software engineer. But your ability to write and communicate can be a tremendous force multiplier for your career.

freshhawk 14y ago
I could not agree with you more. I would also add that it's not just writing those emails or communicating but actually taking the time to understand the office politics/social dynamics of the place you are working. I've seen many talented engineers miss out on the success they deserve because they felt that their specialty being "technical" meant they didn't have to concern themselves with "the politics". Often it's partly true, and it's very tempting to those more introverted than average. Write well first, but after that they should learn to tell exactly who to write to, what tone to take and when they should write to them. It can make a truly astounding difference in your career path.
wonnage 14y ago
Not only is writing important for working with non-technical people, but it's a big part of interacting with your fellow engineers too. Think stuff like providing clear pull request feedback without offending the person you're reviewing. And, if you work in an office that avoids interruptions by using email/IRC, it obviously helps to be comfortable writing out your thoughts. I'll also make the (admittedly unprovable) assertion that good code is good writing. Code and sentences can say the same things in different ways - what's the one that minimizes misinterpretation while remaining concise and interesting to read? Just as you want the key points of an essay to live within the most engaging sentences, important code should look important. Style in programming is as crucial as it is subjective, and it requires you to empathize with your readers much as you would when writing anything else. So yeah, dust off that Tumblr account and use it for something other than reblogging.
tomjen3 14y ago
And I who entered this business because I liked to deal with computers, rather than humans. How do I avoid becoming a writer, while still being able to have a job as a software developer?
- schmrz 14y ago
  Most of us like handling computers more than humans but it's not really that black and white. In order to get the most out of your career you will need to learn how to handle humans too. That of course doesn't answer your question. You can probably keep your job whilst having poor communication skills but that will be a (significant) limiting factor for you.

speakingofprog- 14y ago

This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built and deployed about 4 months ago, it was a week of one developers time start to finish. Ever since deployment there has been bug after bug after bug, every time they fix one bug they break something else. This is an extremely simple system that should (in my experience as a developer) not have any problems. Does this sound normal, for every deployment to have new system breaking bugs? Does this sound something like they're letting junior developers (in skill) deal with systems beyond their scope of understanding? or is it normal for systems to be breaking frequently? This is the only company I have worked for with engineering that affected my work so I'm not sure if this is unique to this company or is common place in the corporate world.

bproctor 14y ago
I've worked at companies where this seems to happen often and it usually comes down to two things: 1) Poor communication and/or planning as far as what the end result was supposed to be. The developer built it the way they thought it was supposed to work, they find out later that it's incorrect or the specifications for it keep changing making the developer add one hack after another to get it to do what it needs to do. They'd probably like to just rewrite the whole thing, but by now it's too late. Jr vs Sr: Sr can see this coming and does whatever he/she can do to minimize it. Doesn't necessarily mean they can stop it from though, it might be too high up the chain of command. 2) Little to no testing. The developer built it and said "done" and then it was passed on to the end user. Anything of any complexity is going to be riddled with bugs if there isn't some kind of QA process in between. Developers typically suck and QAing their own work. Jr vs Sr: Sr has more experience to see possible problems before they become problems and if no QA procedure exists, will at least try to run it by a colleague before claiming it "done".
danenania 14y ago
It's hard to say without all the details. It's also the kind of thing that can be hard to gauge from outside the project. It could be new developers making rookie mistakes. It could be simple incompetence. Or it could be that what sounds simple to you on the surface balloons in complexity after being forced to fully engage with the problem and all its edge cases. If it's closer to the second, it could signify more of a failure of process than a failure of engineering if engineers are being pushed to release quickly at the expense of planning, time for refactoring, qa, unit tests, etc. That "this should be easy, why's it taking so long??!" attitude can create a toxic environment if it's coming from people who don't understand the issues involved.

ericHosick 14y ago

I would fault some of the points listed, like "Embrace Unit Testing", to a failure of Software Engineering as a discipline. Mechanical Engineering, Electrical Engineering, Physics, Doctors, etc. all have bodies of knowledge. We, as an industry and discipline, have no real body of knowledge. Do Doctors have the ability to make up procedure on the operating table? Why is it, then, that we don't have standard practices, like unit testing, and help get these pushed into the educational system? Should students even be learning how to write code without unit tests? Without a backlog (if that is what industry agrees to)? Without an understanding of systems? And so on.

indiecore 14y ago
Software engineering as a thing is less than thirty years old, those other careers have been around for hundreds if not thousands of years, the body of knowledge will come in time.
tjpick 14y ago
No. They are part of the curriculum in a good SE degree. There is a SWEBOK. http://www.computer.org/portal/web/swebok http://www.computer.org/portal/web/swebok
- ericHosick 14y ago
  I found, based on my few years of experience lecturing in IT and BIS at a large university (72,000 students), was that very little emphasis was placed on building up IT as a profession based on a body of knowledge. Really, it just isn't happening. There is a huge disconnect between best known practices, such as those you linked to, and academia.
  - deleted 14y ago
    [deleted]

civilian 14y ago

There are two (4) steps. As someone said: "There are 2 hard problems in computer science: caching, naming, and off-by-1 errors" ;)

larsberg 14y ago

The biggest one I'd recommend is "find a mentor." And I don't mean a manager (unless you're going on that path), but rather a technical leader that you can meet with once a week to month whose opinion you value and can provide you honest feedback on your work. You should plan to drive these meetings; count on them only to show up, drink coffee, and answer your questions. If it is not your most valuable hour of the week/month, you either have the wrong mentor or are handling it wrong. And if your company does not have such a mentor, you should either look to find one that does or make sure you're getting paid well. Author can also follow up with me via e-mail if they want Stanford-specific advice. There are a specific set of things that the perfect-A average and BS+MS degree in CS in 5 years crowd runs into during their first few years out of school that I'd be happy to share. It's true of every school, but we had a lot of experience with the A students from Stanford, Yale, MIT, Princeton, etc., and they all seemed to run into the same problems as their alumni forerunners.

marblar 14y ago
Can I ask what those issues are?
- larsberg 14y ago
  Sure, drop me mail. I'd prefer not to chat about it on a public forum. People (myself included) get defensive about their alma mater, but in e-mail you can just ignore me if you think my gross generalizations from experience are off-base for you :-)
ninetax 14y ago
I agree with this. I had an internship, and the mentor really made it what it was. Even if you can only end up at a mediocre company, if you have a good mentor it will be a success.
bobbyong 14y ago
Great advice on technical mentor! Will start looking for one myself now.

danso 14y ago

I really, really wish TDD, or any concept of unit testing had been taught in my courses. Nothing has improved my ability to understand decoupling, orthogonality, and the importance of naming conventions than test writing. And on days when I can't muster the energy to write heavy code, I can at least write the tests that I know I'll need to pass...and the next day, that heavy code task is practically done. TDD is both a good practice and a great psychological boost.

alinajaf 14y ago
They taught me unit testing at university and I've been using it ever since. It has a lot of benefits. But things like decoupling, orthogonality and naming conventions are worth thinking hard about in their own right, not just in terms of the side effects of TDD. Contrary to popular belief, it's entirely possible to create an unmaintainable mess that breaks regularly and is impossible to extend with near-100% test coverage.

j_baker 14y ago

My advice: don't pay too much attention to what more senior developers tell you. senior != more_talented

novamantis 14y ago
This will slow you down incredibly. Instead of ignoring your seniors/peers, QUESTION their "authoritative" commands. You will learn much, MUCH more that way. It also might put them in their place if they are massive egoists. Never feed the ego.
- j_baker 14y ago
  I would like to point out that I never suggested that one should ignore their seniors and especially not their peers. I merely suggested that seniority only buys a person so much respect. It's important not to exceed that quota.
dbyrd 14y ago
I'm a junior developer and I've found that the old guys lack creativity, but they make up for it with experience. The people who have been programming for 20 years have seen languages/frameworks/libraries come and go, they know what good code looks like and what's just trendy. The more you ask them why they're making decisions you think are retarded the better you'll get at programming.

rjzzleep 14y ago

am i the only one who finds the article only marginally related to "being a junior/senior/antique developer"? i would summarize it as: be smart constantly learn find people that are better than you. but then again, most "seniors" probably never did any of the aforementioned. i met an ex oxford(or cambridge) cs prof who's now doing his own startup a while back. The main thing that struck me was that how willing he was to accept advice, even though he tought one of the first cs courses in the uk.

cpeterso 14y ago

I recommend contributing to open source projects, particularly well-known ones. It is a good way to see how other people and projects work, expand your resume experience, and network with people in other companies.

linpythio 14y ago
That's a good idea.Open source project is good practice for programmer,especially junior.Because you can read and modify others' high quality codes.
- cpeterso 14y ago
  For people looking for a project, Mozilla has a lot of documentation and tools to help first-time contributors. "Contributing to the Mozilla Codebase" [1] documents how to get the code and build your own Firefox. "Bugs Ahoy" [2] is a Bugzilla search engine that filters "good first bugs" based on programming language and interests. [1] https://developer.mozilla.org/en-US/docs/Introduction https://developer.mozilla.org/en-US/docs/Introduction [2] http://www.joshmatthews.net/bugsahoy/ http://www.joshmatthews.net/bugsahoy/

shanelja 14y ago

I'm currently a junior developer and will share the lessons of my experience 6 months in: - Making mistakes will kill you, when you sit at home working on your personal projects and a bug slips through, it's not so bad, you can fix them and the client (or yourself) is normally pretty cool with it. On the other hand, when it's someone elses fault, E.G. yourself, your boss will come down hard on you. That's his project, his clients and his shame, if you make mistakes in a commercial environment, it costs someone money - get in to the habit of being your own quality assurance. - Your wage is shitty. Well, mine is, anyway. You have to learn to deal with this, I could go in to detail about finding housing and the lack of respect you face when you need housing benefits, etc, or can't eat for a few days, but there's no need. Get used to having no money and always put as much as you can aside for that rainy day you think you are immortal from at the moment. - Get used to being the go to guy for all the boring work, no one wants to sit there and refactor spaghetti code or build yet another custom joomla module when they have some cool CSS3 design or some technical challenge of epic proportions to work on. - Give your boss respect, he may be friendly but he isn't one of your friends, you can joke with him but at the end of the day don't forget that this (wo)man pays your wages and evaluates your work, if you're making a lot of jokes but you have a week where your work goes wrong, the evaluation will be that you're the class clown. - Slow down at the start, when everyone goes in to a new job, we work our asses off trying to impress then slow down once we settle in, even more so for a junior in their first role, we want to prove we belong in the industry. The kicker is that this pace is difficult to maintain and once you slow down your boss will notice your apparent lack of progress. - Always be early, never be late. Your boss doesn't notice the fact that you come in early every day (by 15 minutes), what he does notice is the one day you're ten minutes late and unfortunately the hours aren't interchangeable. If you make a habit of being late, you are going to get fired, this isn't college where you could turn up to a lesson 15 minutes late and get a giggle from your peers for being that guy, this is the real world, where lateness isn't tolerated for very long. - Arrogance is bad. You aren't arrogant, but you have an opinion and you come across as it, starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client. Your boss wants to appear to be an all singing, all dancing super coder and until you have a few more years under your belt, your opinion is largely invalid. However, if something is seriously wrong, drop your boss an email or a skype or a campfire (That's a thing, right?) and explain why in the least condescending way possible, if you do this tactically and only at the right times it will look very good on you. If anyone is about to jump in to their first job as a junior or needs any advice, feel free to email me, I normally check it every couple of hours.

xiaoma 14y ago

On tip #1, how big does the chunk of other people's code need to be to teach you about the things he's talking about? I've really enjoyed reading algorithms but struggled when looking at source code for large projects on github. I often feel lost and don't really know how to dig in. Any suggestions?

3minus1 14y ago
I feel the same. I always hear people say to read others code. Really? Like what?
- alinajaf 14y ago
  It depends what you're interested in learning about. I'm a ruby/rails developer by trade so rails is a really good place to start for me. The open source libraries around it like devise, cancan, haml+sass etc are required reading if you're going to be using them regularly. I'm currently interested in C and lower level systems stuff and I've found redis to be a really readable codebase. It's not an introduction to C but provides a good example of how to manage a larger C project.
dougk7 14y ago
I first familiarise myself with what the project does and read the docs, especially if there's an overview of the architecture documented somewhere. Then clone the project locally and open it in an IDE like Eclipse that will allow you to quickly jump between modules and see the structure of the project. Starting from an entry point (e.g the main() function), work your way into the parts you're interested in. If there's any dependency you also want to look into, just clone it and open it as well. I also prefer reading through projects I use either as a dependency or as part of a system I'm building. For that the Apache foundation's projects is an excellent place to start. They have very good documentations and the forums are filled with discussions. e.g Apache Nutch (before the v2.0 release) - there are many talks and slides you can find on its architecture and the source code isn't hard to read. http://nutch.apache.org/ http://nutch.apache.org/ Twitter's github projects are also very good - especially when I started learning scala. One project that I read for fun, it was hard to go through but the exercise was worth it is Chromium. http://www.chromium.org/developers http://www.chromium.org/developers

scott_w 14y ago

Something I learned early on was the importance of stepping back and looking at the bigger picture. A good developer improves this over time, but it's far too easy to get yourself neck-deep in code and lose focus of what's important. As a measure, if I find myself getting stuck, what I like to do is go back to the basic level and ask "what is the purpose of this?" This may involve getting more information about the feature/bug, or just talking through different scenarios. I also look at the likelihood of a scenario occurring. Sometimes, you're spending time trying to solve something that nobody knows or cares about.

Zanyinj 14y ago

I'm also a 'Junior Developer'(around 2yr) and am currently in the phase where I have started to see the faults in the systems my seniors design. There's a module that's driving me nuts, and I'm still pondering on how to tell the senior developer(who wrote it) that it's crap, over engineered and too specific. The module works to an extent, but I can see problems up ahead if the module doesn't get fixed or an alternative is created. I already knew most of the things described, but it's always nice to refresh your memory:) In this stage of my career I'm thinking more and more about going somewhere where software engineers get paid what they are worth (And I'm beggining to realize I'm worth something). With "somewhere" I mean another country. Since mine is becoming increasingly unfriendly to live in. Any suggestions/advice on how to successfully relocate to a job in another country? US or UK come to mind, since there's no language barrier for me there.

thisone 14y ago
This all depends on where you're from. US is easier for Canadians, UK easier for Australians, for example. For non-commonwealth/non-EU residents, the UK has gotten very difficult since 2008 for people who are unable to get an employer sponsored visa. Even to the point of doing away with both the post-study visa and the Tier 1 general. UK salaries also can vary drastically depending on where you live (and not necessarily in tune with cost of living differences). We're also on our way out of the economic mess, so salaries are going to be depressed anyway in general as companies hire on, but use the economic mess as a reason to give lower salaries.
- Zanyinj 14y ago
  I'm from Slovenia, EU resident.
  - thisone 14y ago
    Then the UK should be relatively easier for you, since you should be able to apply for the same jobs as a UK citizen, I think? Beyond that, I'd say google. There should be a number of forums or immigration sites offering advice for EU residents that would like to work in another EU country. (I'm American, so I consider you lucky in the visa world ;) ) Could also look at the Republic of Ireland?

unitesting24 14y ago

Love #6 & #7 - Unit Testing and Refactor. It's such an important practice and best to build the right habits from the beginning. The cost of entry is so low with free mocking frameworks. Even commercial vendors like Typemock got into it with their Basic (http://typemock.com/isolator-product-page http://typemock.com/isolator-product-page)

caw 14y ago

I am what I guess you'd consider a junior sysadmin. I graduated in May of 2011. While it's not being a developer, all of the points stand. Read other code - still very important in admining. Other people write scripts, and there's a wide variety of Perl that's been written. Understand what's good and bad. 2-5 are all true. I just want to reiterate how important it is to ask questions (#4). When you start a junior position, spend time getting to know people. Set up one on one meetings with other people to get to know them and find out what they do. It's important going forward with a cohesive team. From the training side of it, if you're not asking questions I can't be sure that you understand what I'm saying. Unit testing doesn't really apply to sysadmin that much, but basically have a plan to test if something works as you're going along. If you're making 4 major updates to interdependent systems, how can you tell which of the 4 systems broke the service for the user? I ran into that recently. We had a problem that stumped 4 technical experts and two vendors for over 8 hours, when it was a relatively simple fix (once they figured out what the fix was). Systems get more complex as you add things to them, so be sure to test the individual moving parts. Refactoring is still always allowed. I feel as though you can extend this to procedures and processes. Where ever you go, there's always some "legacy" that builds up. If you ever receive the answer "That's just the way it's done" you should absolutely look into refactoring that. Odds are the decisions made back then aren't as relevant, because the base assumptions have changed. That's a major area you can show initiative on and start flexing your wings as your own person.

hawleyal 14y ago

Pfft. On being a developer FTFY

rburhum 14y ago

Matt was the smartest freelancer I ever hired

Tashtego 14y ago

I would add "practice what you preach" to this. Everyone hates the junior developer who says "ugh, this code sucks, it doesn't even have tests." Everyone loves the junior developer who says "ugh, that code didn't even have tests, so I found a seam and added some tests for the new method I added, here's how to run them."