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.
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.
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.
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.
Oh I should have been much more accurate. I hate having to be a communicator, I don't mind handling people -- they are (in aggregate) a pretty interesting bunch and I love to figure out what makes them tick.
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.
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.
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 :-)
Here's a shameless plug for https://www.apprentice.io/ - we offer great (paid!) technical mentorship for 3 months with one of the best Rails firms in the US.
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.
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.
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.
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.
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".
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.
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.
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.
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."
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.
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.
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.
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 ;) )
Companies are increasingly opening up to the possibility of hiring remotely. It is a huge step forwards for any company to take but sometimes the benefits outweigh the risks so it happens [1].
I've been working remotely for about a year. We have a 10hr difference, talk almost every day, and its been great. It's a small company, only two devs, and we all care a lot about the work we do and the products we release.
So, don't limit your search for jobs where relocation is feasible - look for telecommute/remote jobs as well.
[1] The main barriers to overcome are trust and communication. Both parties need to really trust each other (one will do the work, the other will pay) and they need to have open and honest discussions. At the end of the day the job needs to get done and the fact that there's no direct face to face interaction between the people involved needs not to be an issue.
I'm German. I have been living and working in Cambridge, UK, for three years for my first job, and just moved to Singapore to start my second one. Feel free to ask me more specific questions, either here or send an email. (Address is in the profile.)
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.
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/
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
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.
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.
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.
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.
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.
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)
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.
My experience as a junior engineer is completely opposite to yours. I'd also suggest finding another job--your current gig is not offering you a good environment to grow and learn.
Where are you and where is the GP? Cultures around the world are different. My experience as a junior developer in London around 2004 was very similar. Especially that whole "don't be late" thing which really really annoyed me and I'm still coming to terms with.
We do a lot to mitigate mistakes (code reviews, testing, rigorous QA), but when they happen I'm not getting the switch.
We're taken care of w.r.t wages and time. Hours are totally interchangeable here--if I arrive 45 minutes late, I make it up on the back end. I'm also taking care of a graduate degree out-of-pocket (speaks to both the wage and time thing).
I won't speak to arrogance (fallen into this trap, and you don't want to be the guy asserting falsehoods matter-of-factly), but junior devs shouldn't be afraid of assertiveness. I wasn't happy about something here, and when I was asked to discuss it with our tech management team they (a) listened and (b) acted on it immediately. That's big.
I'm located in the north of England, I can't speak for the parent. And yeah, I'm sick to death of the "don't be late thing", my bus comes at an awkward time and it's hit or miss if it's late to be honest (it normally is). Most mornings I have to run to the office.
To be fair I think all of that is good advice if you work at a certain kind of company. At my place of work I don't think any of those apply, nobody tracks your hours for example and you can work from home if you want so the never be late doesn't really work.
And this is from a reasonably sized company (~1500 full time staff)
This does not sound like a positive work environment! This seems to be very unusual.
Also, if you can't make enough to live on, that's insanely unusual in the West.
You need to be able to fail and make mistakes. That's part of being a junior developer. You need to be able to provide intelligent opinions, even contradicting your boss.
But you're right about being aware of the politics and what your boss wants. It's usually bad form to cause one's boss to lose face in front of clients/his peers/bosses.
Your place of work is terrible. When there's a bug in my code, it's because I made a mistake, but it's also because A) my code reviewers didn't catch it, and B) the testers didn't catch it. In a decent organization, blame should be spread and the reaction to problems should be systemic.
> Your wage is shitty
Your place of work is terrible. I had more money than I knew what to do with starting out.
> Get used to being the go-to guy for all the boring work
This is somewhat true, but starting out, many things are new to you, so even if they'd suck for a more experienced dev, it's still good stuff build a foundation 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
I've considered lots of my bosses my friends. Give your boss respect if they earn it. If they don't, complain to someone you DO respect or leave. Also: I've had several reviews mention my sense of humor as a positive.
> Slow down at the start
Don't try to impress anybody. Just do your best because why would you do anything else? And if you're slowing down, it's because they're giving you boring work. Talk to your boss or go find better work.
> Always be early, never be late
Your place of work is terrible. They don't trust you. (My hypothesis: they're projecting their own poor work ethic onto you.) I can work 7am-4pm, or 8-5, or 9-6, or whatever. I can come in late whenever and nobody bats an eye, because I am trusted.
> Arrogance is bad.
Sure, of course, so just mind how you speak. Be good-natured and generous in your assessment of others.
> 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.
Your place of work is terrible. Nobody should expect you to be a genius, and your opinion does matter. If they respected you, they'd ask your opinion, and constructively criticize your ideas so that you improve.
In case I forgot to mention it: your place of work is terrible. It is not like this everywhere. Don't start feeling trapped, though: feel empowered. You deserve better.
I'm currently a, "something" developer this is what I would tell you over a beer after a hard days work in the salty salt mines of programming, after 6+ years on the job.
> Making mistakes will kill you
Nah they won't. No matter how it's worded, your current agreement with your employer is actually something like: "We agree that you will make mistakes and learn on the job. In return for this we will pay you peanuts". If they wanted a senior developer, they should be paying for one.
It's also important to point out that the mistakes you make now will play a big part in making you a senior developer. If you're putting yourself out of your comfort zone often enough you should be make plenty of mistakes on a weekly basis. It's nice if like you say, you catch them before your boss/clients do, but I wouldn't beat yourself up too much if you don't.
> Your wage is shitty.... or can't eat for a few days
Leave. Even with only six months of experience you're probably worth at least double what you're getting paid now. That a developer can't eat, in this market, is truly fucking ridiculous.
> 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
Refactoring spaghetti code doesn't go away when you become a senior developer, and it's a massively important skill to build up. Most non-trivial projects on big systems will require that you do this. I know it doesn't feel like you're learning anything, but reading code is a hugely important task that junior developers need to do more of (as opposed to just writing it).
The more you do this, the better you will get at understanding big systems quickly. Learn this now, do it at future clients 1, 2, 3, and 4. By the time you do it at client 5, you'll be so good at it that they'll think you're some sort of prodigy (so get paid accordingly!).
> Slow down at the start,... your boss will notice your apparent lack of progress
Who cares? If your boss has a problem with your progress he should let you know and you should work together to improve it. Also: Leave!
> Always be early, never be late. Your boss blah blah...
Personally I like coming in at the crack of dawn and leaving very early. I know other wickedly good developers who prefer turning up at 11 and leaving at 8. Non-developers don't get this, but it's fine. As long as you're delivering results and are available for any in-person rituals, no one should really care what time you arrive/leave.
> Arrogance is bad.
You say that now, wait a few years. When you've surpassed your heros in terms of skill/knowledge and spend most of your time watching other developers wrap themselves into webs of complexity for no good reason (and then have to clean up after them), then tell me not to be arrogant. A strongly worded opinion, arrogant or not, has demonstrably saved months of work and oodles of money for clients down the line.
> starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client
Bzzzt, wrong again! Expressing my opinion in front of clients, even as a junior developer, has consistently been a positive experience for everyone involved, including my boss's at the time. "No, that's wrong" is admittedly a little strong, but it really depends on the content. "No, that's wrong, the google search algorithm works like X so you'll probably have better results doing activity Y" or "No, that's wrong, if instead we make it a RESTful API we get the following 3 benefits..." is a hell of a lot more useful to everyone in the room than you just sitting in a corner being demure.
> Your boss wants to appear to be an all singing, all dancing super coder
I don't think I like your boss very much.
Based on the attitude you've displayed in this post, by any metric you're probably better than you think you are. The worst sort of junior developer is one with no humility, but I think you can afford to be a little more confident, especially when dealing with "Your boss". Also, Leave.
I don't agree with your comments about arrogance. You can be right and strongly opinionated without being arrogant. Junior or senior -- making anyone, boss or not, look bad anywhere, but especially in front of a client is a perfect way of finding yourself at the business end of some pretty nasty social dynamics.
Practice voicing your opinion and arguing for it in a way that isn't confrontational. 9 out of 10 times, it's as simple as acknowledging the other person: "I see where you're going with this, it's a good way to solve A, B and C. But when we get to D, I fear X will bite us in the tail - Y can avoid that.". This also avoids the stinging embarrassment of being arrogant and later being proven wrong.
> "I see where you're going with this, it's a good way to solve A, B and C. But when we get to D, I fear X will bite us in the tail - Y can avoid that."
In practice, I word things similar to what you've described here, probably even more deferent.
Still, if I believe it is in a clients best interest to do Y, I don't mind sticking my neck out and make the case more strongly for it, even if I turn out to be wrong.
Additionally, I've found over my career that I've learned the most useful skills, both technical and otherwise, from developers who were fantastically arrogant. They also happened to deliver the most value to the business, so no one cared.
You can be arrogant if you're brilliant - not the other way around. As a junior engineer (in the 'not much experience', not 'pay grade' sense), you're probably not brilliant enough to be arrogant.
Thanks for your advice and information - personally, I agree with a lot of the points you've made.
The problem is that at the time I took my job, I didn't have much choice, I was in a shitty position, no job, no money, no home, etc. and I took the fist position which came along.
I wish I had been in a better position and been able to better evaluate my current workplace, but in my bosses defence, I am the first (out of family) employee for this oompany, my boss is new to the world of being a boss too and he is unsure of when and where to show his authority.
As for moving elsewhere, I am currently in the process of applying for other jobs and hoping one of them come through.
I should state that I actually like my boss, he's a good person and is as new to being an employer as I am to being a commercial programmer.
I would like a more professional and tactful environment in my next position but I don't in any way blame my boss for how I feel, in fact I have a lot of respect for him.
>> The problem is that at the time I took my job, I didn't have much choice, I was in a shitty position, no job, no money, no home, etc. and I took the fist position which came along.
No shame in that. I graduated in 2001, and was ecstatic to receive my first (and only) job offer. 1.5 years later, the company went bankrupt, and my team of ~7 was sold (OK, the IP was sold, the team got offers). News came out that one person on the team was getting a raise during the transition and that person was me!!
...because the new company didn't have a pay grade that went low enough to accommodate my existing salary. :/
About 5 years later I cracked 6 figures in the Midwest U.S. and I'm not a super/rock/ninja/adjective du jour star by any stretch. My $.02: Keep working hard, know what you want (and don't be afraid to ask), communicate well, and generally be a Good Guy/Gal™. The rest kind of fell into place for me and my guess is that it will for you too. Best of luck!
You're preaching the virtues of submission. Don't let others make you feel this way.
- 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.
Mistakes won't kill you. Pain must be felt. Risks must be taken. Take responsibility for your work but remember that being protected from the reaction to your work is bad.
- 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 confidence in your own abilities and then solve the money problem. Get confidence by being really good. And I don't mean wait for your boss to tell you that you're good, I mean look around Hacker News and find those that are good and then do as they do.
- 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.
Don't give anybody respect just because they have authority to evaluate you. Give them respect because they are worthy of your respect. Do your best; if you're cracking jokes and things go wrong, it's significantly better than if you were being dead serious and things went wrong. A positive, fun atmosphere increases the chances of people working well together and getting shit done.
- 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.
Care about being right, constructive and doing lots of high quality work. I wouldn't give a fuck if somebody thought my opinions were 'largely invalid' because there are few opinions in technology: when you want to win you should call upon hard facts! If you want you can massage your bosses ego a little bit but all of this talk of turning up early and bowing to people even when they are wrong has little to do with good business and everything to do with egos and social decorum.
Currently, moving to London isn't possible for me, I've been with my girlfriend for 3 years now and I have to take that in to account when relocating is considered.
That aside, I agree with a lot of what you've said, I'm currently feeling pretty shitty about my job and actively seeking work elsewhere (and being interviewed, etc).
Out of curiosity, why do you propose a relocation to London?
> Out of curiosity, why do you propose a relocation to London?
Not sure about the OP, but the London market has been screaming for web developers for the past three years at least and I would be very surprised if it slowed down any time soon.
To give you concrete numbers, I came off a contract at the end of October (I'm taking a few months off for baby arrival, due any day now) and went to one local user group event to line up some new work for January.
Based on that outing and pinging a couple of recruiters, I have two potential clients who have given me offers for 3+ month contracts, another two interviews next week and the client I just finished with wants to re-contract too. None of the new clients are referrals. Daily rates (subject to change!) circa £500.
I get regular emails from past employers asking for recommendations for full-time developers too. In the vast majority of cases, I have no one to recommend as all of the good full-timers I've been in the foxhole with tend to be quite happily employed.
Don't feel shitty. Concentrate on what you can achieve on a personal level: programming languages you want to know, projects you want to start, and very importantly attitudes with others that you want to hold.
But understand that while you might be able to become great, you're in Lancashire. There aren't going to be as many big deals going on there.
> Currently, moving to London isn't possible for me, I've been with my girlfriend for 3 years now and I have to take that in to account when relocating is considered.
Move to London together, perhaps? You can probably make more alone there, than your two wages together at the moment. (Add in a London job for her, and it becomes even better.)
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.
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.
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.
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.
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.
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.