PHP Code Examples for Resume Site?

[Garethp]

So, I was considering building a website to accompany my resume, and hopefully start off a freelancing career, and I was thinking of building some examples on GitHub that might be useful for getting me jobs. Being a PHP programmer, all of my jobs so far have been private, and I can't just link to the work I've done. So I was curious what projects would be good, from a hiring stance, to showcase my skills to potential employers. I'm not sure if this would be the same as the list of projects to tackle if you get bored, but if so just let me know. So tell me PHPFreaks, what would be some good ideas to develop code examples for employment prospectives?

 

PS: Forgive me if I'm posting in the wrong place, or if my posting style is wrong for this forum, I haven't been around these parts in a while

[trq]

It depends on the jobs your after really. Doing something just because you think it might help with your job prospects is unlikely to help your cause much though. Most employees like to see passion, and there is nothing passionate about doing something just because you have too.

 

Find something that interests you and go with it.

 

Contributing to open source caries a lot of weight at certain companies, so that could be a good place to start.

 

My last 2 jobs have both come from people seeing my Github profile and liking what I do.

[Garethp]

It depends on the jobs your after really. Doing something just because you think it might help with your job prospects is unlikely to help your cause much though. Most employees like to see passion, and there is nothing passionate about doing something just because you have too.

 

Find something that interests you and go with it.

 

Contributing to open source caries a lot of weight at certain companies, so that could be a good place to start.

 

My last 2 jobs have both come from people seeing my Github profile and liking what I do.

 

You're from Sydney, so maybe you can suggest other ways of finding contracts/jobs? The reason I want to do something to put on a resume site is because all of my work so far has been private. Backend work that I can't link and can't show the source code, which sucks because personally I believe that my code style says a lot about me, and I want to have something to show people, you know? So far I've only gotten jobs through seek.com.au, but for some reason I get the feeling that seek only has a partial view of the job market. For example, why is it that 90% of the time I apply for a job I go through recruiters? How do I find jobs in Sydney that don't go through recruiters? Are there more jobs sites? How do I get my name out there?

 

Sorry for all the questions, but you raised a good point about it not helping my cause. It won't stop me from doing it though, because I want to be able to showcase my skills. And after your point well raised, I'm not quite sure what the best way is to get better jobs. It's not like I'm doing poorly in the job market, I just have this well of ambition that demands that I rise higher, but I'm not sure how to do that...

[.josh]

Why can't you mention your freelance work on your resume? As long as you aren't trying to puff it up to something unbelievable like claiming you single-handedly dev'd facebook or something.. Even if you can't post a direct link or include phone numbers (which you shouldn't really do anyways), you can still mention the projects and what all you did.

 

The reason I want to do something to put on a resume site is because all of my work so far has been private. Backend work that I can't link and can't show the source code, which sucks because personally I believe that my code style says a lot about me, and I want to have something to show people, you know?

This is where you are wrong.

 

99% of the time, resumes aren't really about proving you did xyz. Even if you could link to xyz.com, that doesn't prove you did it. Resumes are about summarizing your experience and qualifications. Even if/when you get called for an interview, it's not so much about proving you did xyz as showing that you know wtf you are talking about, especially how it can be usefully relevant/applied to the company's needs, and presenting yourself in a way that makes them like you.

 

 

And "Showing you know wtf you're talking about" rarely involves pointing at xyz.com or some chunk of code you did. Handing someone code doesn't prove you did it or didn't just c/p it. It usually involves answering whatever scenario/knowledge questions they throw out at you, or completing some "test" they've devised.

[trq]

As .josh has pointed out, you don't really need to prove you have done something to put it on your resume, you just need to prove you know what you are talking about.

 

For me, that sort of thing comes across better in your cover letter. My cover letter is a good solid two and a half pages that introduces me, how I got into development, the kind of stuff Ive worked on and my interests. While doing so it showcases my personality.

 

I have never shown an employer any portfolio of sites I have worked on. Most of the stuff I have worked on has been private intranet applications.

 

Having said that, its obvious I know what I'm talking about when people read my cover letter and than latter have a chat / interview with me. I also have quite a bit of code on Github spanning a number of years and different languages / interests.

 

I didn't realise you were from Sydney. Depending on what your looking for the job market in Sydney can be tough. Ive just been lucky I guess. The last two places (including my current job) I have worked for managed to find me through contributions I had made to open source. Before that, I had been freelancing for a little while, and before that I had moved up the ranks at a company I ended up being with for 12 years.

 

We should catch up on irc and have a chat sometime. I didn't realise you where so close (I'm actually on the central coast though - not Sydney itself).

 

Anyway, what I'm really getting at is, if you can afford the time, getting involved in open source is a big plus if the companies your interested in appreciate it. On that note too, you should be actively seeking companies your want to work for. Don't just go for any job. Find the place you want to work and make sure they become aware of you.

[Garethp]

As .josh has pointed out, you don't really need to prove you have done something to put it on your resume, you just need to prove you know what you are talking about.

 

For me, that sort of thing comes across better in your cover letter. My cover letter is a good solid two and a half pages that introduces me, how I got into development, the kind of stuff Ive worked on and my interests. While doing so it showcases my personality.

 

I have never shown an employer any portfolio of sites I have worked on. Most of the stuff I have worked on has been private intranet applications.

 

Having said that, its obvious I know what I'm talking about when people read my cover letter and than latter have a chat / interview with me. I also have quite a bit of code on Github spanning a number of years and different languages / interests.

 

I didn't realise you were from Sydney. Depending on what your looking for the job market in Sydney can be tough. Ive just been lucky I guess. The last two places (including my current job) I have worked for managed to find me through contributions I had made to open source. Before that, I had been freelancing for a little while, and before that I had moved up the ranks at a company I ended up being with for 12 years.

 

We should catch up on irc and have a chat sometime. I didn't realise you where so close (I'm actually on the central coast though - not Sydney itself).

 

Anyway, what I'm really getting at is, if you can afford the time, getting involved in open source is a big plus if the companies your interested in appreciate it. On that note too, you should be actively seeking companies your want to work for. Don't just go for any job. Find the place you want to work and make sure they become aware of you.

 

Sorry for the late reply. I would have replied to .josh, but I didn't really have anything more than "I agree and you opened my eyes". I guess because I'm only 21 and trying to shoot for Senior positions I feel like I have something to prove. Not knowing how to write a Cover Letter (and thereby not really bothering with them, just sending in my Resume) and not knowing if I'm quite good enough doesn't help. I would go for the companies that I want to work for, and write Cover Letters for them, but in my few years in the job market I've noticed that most companies I work with take years to really implement bigger changes, while I want to be learning something completely new every few months. I've been contracting for the last year and it's rather helped me satisfy my urges to challenge myself every couple of months. I know if sounds like an excuse, since I could learn the things even if the companies I work for don't implement them, but it doesn't feel like I learn quite as much or quite as well when I'm not just thrown into it and forced to learn how to do something knew, you know?

 

Yeah, I'll have to jump onto the PHPFreaks IRC some time. To be honest when I joined the internet (All of 8 years ago), IRC was kind of popular, but I always felt like it was dying out. If IRC is still kicking happily, I'll have to reassess that and spend some time chatting away on it.

 

I really should join some open source projects, but I'm not quite sure where to start. I mean, the only skills I feel confident enough to use to contribute is PHP/MySQL and JS/HTML/CSS, and all of the projects I see in those areas are all already so full of more talented, more skilled people than me that I just don't know what to do. How does one find a project that hasn't already got enough people?

[.josh]

TBH I think you're probably being a bit unrealistic if you're trying to shoot for a senior position right out the gate.  Not that I'm saying you are/aren't capable, but there's a lot of office politics involved, and even if you include your freelance projects on your resume, that might get your foot in the door as a peon but from my experience, probably isn't good enough to land a senior position. And TBH I'd probably be weary and suspect of working for a company that does offer you a senior position right out the gate like that. It can mean several things. It can mean that the company has no real direction or policy as far as coding is concerned, which will inevitably lead to unrealistic expectations, not enough pay, etc.  Or think about if you were the current peon working there and someone walks in as your boss.  That shit rarely works out. Either you're "cool" and listen to the peons in which case their opinions of why they aren't running the show are reinforced, or else you tell them shit needs changing, but you don't know the context/history of shit.  You're pretty much fucked either way. 

 

So basically, even if you have a killer resume, it's usually better to shoot for getting your foot in the door and working your way up, instead walking in as commander-in-chief, unless the "senior" position is more about abstracts, like project management, direction of the company, etc..(which doesn't really sound like what you wanna do anyway?)

 

Also, you aren't going to really find many companies that don't take "forever" to implement stuff.  Again, there's a lot of office politics and red tape when it comes to implementing stuff.  I swear, I have logged dozens of hours in dozens of meetings across literally months for even the smallest "one liner" things.  General rule of thumb is, bigger the company, longer shit takes to get done.  Exponentially. 

 

So on that note, if you're looking for a faster pace, I suggest you skip trying to jump on board with an individual company, and try shooting for getting in with an agency or some other company that's all about providing code/support for other companies.  Basically it's kinda the same principle as freelance work, but you focus on the coding while other people on the team focus on landing the clients. 

[dalecosp]

Can you set up a VM "dev box" on a laptop and take your projects with you?

My employer didn't have many "code gurus" and wasn't too interesting in seeing the code ... they wanted to look at what the code produced.

Dev sites/projects worked well for that.  I set them up on a private VM and took the laptop to the interview.  It seems to have worked....

[Philip]

To be honest when I joined the internet (All of 8 years ago), IRC was kind of popular, but I always felt like it was dying out. If IRC is still kicking happily, I'll have to reassess that and spend some time chatting away on it.

 

 

In the developer world it is still pretty popular. It's a great way to find quick help from collective developers on a topic. Most large open-source projects have their own IRC channel somewhere, usually freenode.

 

 

I really should join some open source projects, but I'm not quite sure where to start. I mean, the only skills I feel confident enough to use to contribute is PHP/MySQL and JS/HTML/CSS, and all of the projects I see in those areas are all already so full of more talented, more skilled people than me that I just don't know what to do. How does one find a project that hasn't already got enough people?

 

Go to GitHub, find a project that you like you you've used and fork it. Fix a thing or two, add a new feature and do a pull request. I welcome it when someone does this to my GitHub projects; it's a nice feeling as a project owner that people are using your stuff. Once you've found your groove on what you like to contribute to & you get the chops, start releasing your own projects. Then, as trq pointed out, people start to notice you. 

 

 

TBH I think you're probably being a bit unrealistic if you're trying to shoot for a senior position right out the gate.  Not that I'm saying you are/aren't capable, but there's a lot of office politics involved, and even if you include your freelance projects on your resume, that might get your foot in the door as a peon but from my experience, probably isn't good enough to land a senior position. And TBH I'd probably be weary and suspect of working for a company that does offer you a senior position right out the gate like that. 

I have to agree with this. It's very rare I see someone straight from college (or with X years experience) not have a junior or mid-level position before a senior position. Many senior positions require a lot of field experience. I'm in a relatively niche field myself, but a lot of the "senior" positions require 5-10 years minimum of hands-on experience in the industry. Just my $0.02.

[Garethp]

TBH I think you're probably being a bit unrealistic if you're trying to shoot for a senior position right out the gate.  Not that I'm saying you are/aren't capable, but there's a lot of office politics involved, and even if you include your freelance projects on your resume, that might get your foot in the door as a peon but from my experience, probably isn't good enough to land a senior position. And TBH I'd probably be weary and suspect of working for a company that does offer you a senior position right out the gate like that. It can mean several things. It can mean that the company has no real direction or policy as far as coding is concerned, which will inevitably lead to unrealistic expectations, not enough pay, etc.  Or think about if you were the current peon working there and someone walks in as your boss.  That shit rarely works out. Either you're "cool" and listen to the peons in which case their opinions of why they aren't running the show are reinforced, or else you tell them shit needs changing, but you don't know the context/history of shit.  You're pretty much fucked either way. 

 

So basically, even if you have a killer resume, it's usually better to shoot for getting your foot in the door and working your way up, instead walking in as commander-in-chief, unless the "senior" position is more about abstracts, like project management, direction of the company, etc..(which doesn't really sound like what you wanna do anyway?)

 

Also, you aren't going to really find many companies that don't take "forever" to implement stuff.  Again, there's a lot of office politics and red tape when it comes to implementing stuff.  I swear, I have logged dozens of hours in dozens of meetings across literally months for even the smallest "one liner" things.  General rule of thumb is, bigger the company, longer shit takes to get done.  Exponentially. 

 

So on that note, if you're looking for a faster pace, I suggest you skip trying to jump on board with an individual company, and try shooting for getting in with an agency or some other company that's all about providing code/support for other companies.  Basically it's kinda the same principle as freelance work, but you focus on the coding while other people on the team focus on landing the clients. 

 

I see, that definitely changes how I'm going to approach this, thanks

In the developer world it is still pretty popular. It's a great way to find quick help from collective developers on a topic. Most large open-source projects have their own IRC channel somewhere, usually freenode.

 

 

 

Go to GitHub, find a project that you like you you've used and fork it. Fix a thing or two, add a new feature and do a pull request. I welcome it when someone does this to my GitHub projects; it's a nice feeling as a project owner that people are using your stuff. Once you've found your groove on what you like to contribute to & you get the chops, start releasing your own projects. Then, as trq pointed out, people start to notice you. 

 

 

I have to agree with this. It's very rare I see someone straight from college (or with X years experience) not have a junior or mid-level position before a senior position. Many senior positions require a lot of field experience. I'm in a relatively niche field myself, but a lot of the "senior" positions require 5-10 years minimum of hands-on experience in the industry. Just my $0.02.

 

Hm, so basically having 3-5 years on my resume isn't enough to go for a Senior Developer position? In most companies I have to work my way up from Mid to Senior?

 

Alright, I'm going to try to look for some PHP projects that could use an extra hand or two

[.josh]

Well it really depends on how the company defines "senior". I have seen many companies who base those titles solely on tenure with them. It doesn't really matter how well you know a language and coding practices in general. Well it does certainly matter, but that's just an "entry point" requirement in the grand scheme of things. You have to understand that everybody's code and situation is unique. I'm sure you understand this on some level, but it sounds like you don't have much experience to really understand how much having a history and understanding of the context really weighs in comparison, and that comes from experience working with a specific company, not having work experience in general.

 

It's a trap that many in "agency" positions fall into a lot. Myself included. I'll be tasked to audit a client's site and at face value the code looks really shitty and I can't help but wonder how dumb the client's devs had to have been to have done xyz. And it's only after spending some time talking to them and really diving into things like history of emails and why's and how's of things that I begin to understand that development from a company PoV is 5% actual coding and 95% politics. IOW that shitty bandaid/hack you found probably wasn't because the web dev being an idiot, but because they had no choice in the matter due to budget or time constraints, or not being able to touch a certain piece of code, etc.

 

3-5 years is probably enough to ask for more than entry level wages, depending on how competent you can show yourself to be. And you might be able to negotiate a "trial" period to get up to speed and depending on how fast and well you get up to speed with their history/context, and get fast-tracked to a more senior position. But you're being unrealistic if you expect to be handed something more than an entry level title on day 1. Bottom line is NOBODY is going to drag you to a meeting with a client under the title of "senior" when you've still got a learning curve to overcome.

 

Ideally every level of coder at the company should be proficient in the language and best practices. It doesn't matter if it took you 1 month or 10 years to get to the point of calling yourself "expert" at the language/practices. That's entry level requirement regardless. Nobody hires coders that don't actually know how to code (well they do, but that's because people talk a good game. Ideally they don't). The difference between newbie and senior is having actual history and knowledge of context/policies for the company specifically. IOW you know the syntax - great! So does everybody else there. But do you know WHY they did it this way vs. some other way? etc.

 

It doesn't mean your 3-5 years of experience count for shit. It just means that that's what helps get you in the door. It tells a company that theoretically you a) have a good working knowledge of the underlying technologies, b) have learned a few general tricks and caveats along the way, c) managed to not suck enough to have been able to work the job in general vs. quitting early on. It also tells them you might have less of a learning curve in general, as far as getting up to speed with their situation. But at the end of the day, it's a gamble on their end. There's no guarantee you aren't lying about a given thing on your resume. It's real easy to sound like you know wtf you're talking about, esp since most of the time the interviewer knows very little about the job you are applying for (more office politics). So your experience absolutely means a lot - as far as getting your foot in the door with a decent starting package.

 

And that doesn't mean there's no exceptions. There's always exceptions. It could very well be that you find a place that just lost their coder and they are trying to get *a* coder on board because they have nobody, and you are the "senior" guy by default. It could be that they are about to do major changes like move everything over to a whole new system or otherwise effectively start from the ground up, and perhaps they need someone with experience you have that their current coder(s) don't have. But like I alluded to previously, those exceptions are double edged sword to be weary and suspect of.

[.josh]

p.s. - i'm not trying to deter you from puttin' your feelers out there..just sayin' that in my experience, coding for the corporate world has little to do with actual coding and very much to do with playing the corporate game.

[KevinM1]

I think it's also important to note that:

 

1. 3-5 years experience really isn't anything special.  I'm not trying to sound harsh, but if you look at non-web software development gigs, you'll see that they require a BS in Computer Science plus at least two years practical experience.  And that's just to have them not ignore your resume outright.  So, no, 3-5 years isn't really adequate to even think about a senior position.

 

2. You do realize that a Senior Developer is usually a management position, right?  What's your experience in leading other developers?  In being able to successfully allocate time and resources for everyone under you?  To regularly meet with the business and/or PR arm of companies to keep everything on track?  To have (one of) the final says in app design?

 

Josh and trq have been pretty gentle with this whole thing, but here's the truth: if you go into an interview and say "Hi, I'm 21 years old with 3-5 years experience, and I'm applying for the Senior Developer position," you will be laughed out of the building unless you have an impeccable portfolio with references (to corroborate the management portion of the job) to match.  It's just wholly unrealistic.

[Garethp]

Thanks for setting me straight guys, it's this kind of knowledge that I didn't know about the job market that's useful

 

@.jsoh: What exactly do you mean by entry level? I mean, I've been doing "Mid" level jobs for a couple years now, and I'm not sure what an Entry level wage is? But thanks for your post. I've had my fill of internal politics, and with your help I can now maybe avoid a couple more companies that are too rife with them

 

@KevinM1: I um... actually didn't know that to be honest. I just thought Senior was a designation of skill level and pay grade. But thanks for your blunt-ness, it's really helpful

[.josh]

Well, "entry" level is more or less straight forward. You start out as bottom of the totem pole. You will very likely start out with lower pay than everybody else on your level, even the guy sitting next to you with the exact same title if (s)he's just been there longer. Your responsibilities could basically be summed up as "Do what someone (anyone) else tells you to do." Nobody reports to you, you aren't really involved in decision making processes except possibly by virtue of being the only person on the team doing what you do (e.g. being the sole developer of the company).

 

"Senior" level positions usually focus more on project management and decision making than actual coding. Though this is usually highly dependent on work load vs. work resources. Think of it kind of like a shift manager at taco bell. Ideally they shouldn't be running a position (making or taking the order) at all. Ideally they are responsible for making sure the other employees are doing their job, handling problems that come up, doing paperwork type stuff like nightly inventory, etc. But in reality more often than not, someone calls in or there's not enough employees to schedule in general, or maybe things just get real busy, and they have to jump in and help make or take orders.

 

But when you get into terms like "Medium" level.. well things get pretty fuzzy and highly subjective. In my experience, there usually isn't even a title step between "web developer" (or jr. web developer) and "senior web developer". Traditionally, "Senior" is the next step up. After that, you start getting into titles that definitely do not involve actual coding at all, such as project manager, department manager, etc.. and those positions more often than not can be filled by people who don't even actually have real coding experience, because they basically never do any of the actual coding.

 

So perhaps to a degree, "mid" level is the same as "senior" level for your purpose/ambition. Which brings us back to expectations on landing a senior position walking in the door.

 

Overall I get where you're coming from. You aren't some newbie trying to figure out his first "hello world" program. You have a few years experience under your belt and perhaps you even consider yourself an expert at the language(s) and coding practices you know. But my point is that simple knowledge of these things doesn't really warrant walking in with a "senior" title and compensation (pay rate, benefits, whatever), because a huge chunk of that comes from actual tenure with a company.

 

It's like if you were to work at Burger King for 5 years and know their menu and register system inside and out.. and then walk in and apply for a job at McDonalds. Sure, you know the general idea of how to flip burgers and take orders, but the system and menu, food handling procedures is not the same. Can/Will/Should you be able to fastrack to square 2 quickly, given your prior experience? Absolutely. But that doesn't change the fact that you ARE on square one walking in the door, and you DO have that learning curve to overcome. "Actions speak louder than words" is the apt saying here. You can have a mile-long resume that's thoroughly impressive and it will certainly help getting your foot in the door, but most clients try very hard to pay you based on what you've proven to them you can do, not by what you say you can do. And you prove it to them not by showing a list of past experience. Doesn't matter if you can get Bill Gates himself on the phone to verify you are awesome. Bottom line is their company has its own unique issues and code etc.. and proving your mettle to them involves actually working for them. So 9/10 times the way it works is you tell them what you can do (resume), they decide you seem promising enough to gamble on and hire you, then after working with them a while, you start getting raises and promotions based on what you actually do.

 

"Okay, so then how much SHOULD I expect to get paid then?" This is not an easily answered question. In fact, I would say it's not really answerable at all. There are too many factors to consider. Here are a few:

 

- Location. Different parts of the world have different costs of living. For example, people in the Middle East and Asia generally work for substantially less than in America, because the cost of living is substantially less. And someone living in Midwest America usually gets paid a lot less than Someone working in the upper-eastern area. And it's a two-way street. And it's 2-fold. If the company is located in a high cost of living area and you work remotely in a low cost of area, that doesn't necessarily mean they will compensate you based on where they are located. In fact, they will more often than not compensate based on whatever benefits them. They will absolutely bust out the "you live in lower area" card, but if the situation was reversed, they will absolutely bust out the "that's your problem.. move here and work locally" card.

 

- How big the company is. A mom-and-pop company will likely pay less than some corporate giant. On the other hand, a corporate giant is more likely to have a lot more resources and potential candidates and in general be in a better position to offer you a lower wage and if you don't like it.."next!" On the other hand, a well established corporation will likely have well established policies and clear paths forward and can afford to stick to it, and have higher probability of being in business tomorrow. So the chances of you getting paid more sooner or later is higher.

 

- Company track record of employees. A company who has a hard time retaining employees will likely offer higher wages in an attempt to keep people on board. On the other end of that spectrum: if average employee tenure is long, they may hire at higher wages so that there isn't as big a gap between newbie and veteran, in order to keep newbies from leaving.

 

- What the company actually sells vs. what you actually do there. This is sort of broad. For example, if it's some company that primarily sells physical goods/services, and their website is little more than a fancy business card.. well you probably aren't going to have much to actually do. Expect to be paid accordingly. But if the company's website is huge and complex and especially if it's something "unique" to the company, then you should expect to have a lot more to do and therefore get paid more. And on that note...

 

- How unique the company-specific skillset is. I'll use my own industry as an example. I work in Web Analytics. The (implementation) technology is primarily javascript, though it does span other things such as tracking stuff within flash, or via server-side coding, etc.. but for the sake of simplicity, let's keep this example solely on javascript. Now, there is a big difference between someone who knows javascript, vs. a javascript coder who understands the point and principles of analytics. There really aren't a whole lot of web devs out there who even have web analytics on their radar. There are even less that have experience beyond little more than basic c/p implementation "that one time". There's even less who do it regularly, and even less who do it well, especially as far as understanding the reporting side of things. Basically the point is, it's kind of a niche position, and therefore generally demands a higher salary, despite actual coding experience being (somewhat) less demanding.

 

But having said all that.. in general, there are plenty of sites out there that you can look up average salaries for xyz industry/job etc. to get a ballpark figure. For example, most "job hunting" sites (e.g. monster.com, glassdoor.com) provide some insight on that count. These sites mostly rely on people submitting their own experiences, location, etc. In general, those are good places to find ballpark expectations. But like I said, there's so many variables that are unique to each company that you should take it as a grain of salt. Better than nothing, but little more than that. It's kind of like shopping for a car or a house. You can do some research to get a general idea, but in reality it really boils down to sitting in front of the company, figuring out exact expectations on their end, and then trying to sell yourself to them. But the main takeaway here is to focus on getting your foot in the door with them promising to bump you up to that senior position upon proof of working with them, vs. trying to get them to just hand it to you walking in the door, because as Kevin so eloquently put it, if you attempt the latter, more often than not you will just be laughed out the door.

[ignace]

but because they had no choice in the matter due to budget or time constraints

I know the feeling all too well. Been there myself, and swore then that I would NEVER do it again. A while back it seemed I would have to violate what I had sworn to never do again when the project manager requested an estimate for a rather big change in some existing software we wrote a half year ago, I knew what I had to do, which tests to write, and what to refactor, and how the new model would have to look, I told him it would take 5 days but they couldn't sell that to the client and forced me to reduce it to 2. I agreed physically.

 

When I had to execute the work I set out for the work on my original estimate 5 days. At the start of the 4th day the project manager requested to speak to me privately at which point he realised what I had done.

 

We argued and I told him you have 2 options: you either let me do my job or fire me. I don't do half-work.

 

And I am still employed, and they now listen when I give them an estimate.

 

Employers are not fans of puritans, they like rapid succession of successes at the cost of those that do the work. Don't expect to be ever thanked by them, but your colleagues will praise you. Like when we had this new hire who told on his review that he is amazed of not having to deal with shitty code with older projects as he had to on previous jobs, these are the moments that the project manager is glad to have you on his team.

Edited January 26, 2014 by ignace

[.josh]

ignace that's cool and I'm glad it worked out for you, but when you say this to your boss: "You either let me do my job or fire me. I don't do half-work," more often than not he will choose the latter. Or else choose the former because it's better than nothing at the time - and then start focusing on replacing you. IOW I would not recommend this approach for most people in most situations. If you're going to stand up to your boss like that, make damn sure you really are irreplaceable or else you don't really need the job.

 

I won't sacrifice my morals for a buck. For example, you will never catch me willingly code for a porn site. But the whole "shitty code for shitty timelines" thing.. that's not really morals, that's pride. And while I certainly strive to be proud of the work I do, I am just as certain to swallow my pride to keep my job if it's not violating my morals. I do the best I can do with what I'm given. I make sure it's abundantly clear that someone understands what they are asking for and what they are getting and how shitty it is. If the say they want it anyway, why should I continue to protest? Refusing to do the job unless I can do the best I can in optimal settings is, IMO, usually a foolish thing to strive for, and something very few people can afford to get away with.

 

It's a balancing act, for sure. There's always going to be a certain level of mutual exclusion between "Doing it right" and "Doing what you are told." Just remember, at the end of the day, your boss is the one in charge making the decisions. He can't do his job if you are insubordinate. He may very well be a dumbass making a wrong decision, but it's his decision to make. He's not paying you to make the decisions; he's paying you to do what he tells you to do. If that weren't the case, then he wouldn't be your boss. If he's that much of a failure, go over his head and appeal to his boss. Because I guarantee you that 99% of the time you will get fired over insubordination no matter how right you are.

 

And saying "Well then they aren't worth working for" looks really pretty on paper, but just doesn't work out in reality for most people. Truth is, "We'll consider your input when making a decision, but when we decide and give you instructions, you will do it or we'll kick you to the curb" is pretty damn universal. So unless you're financially secure and only doing work for the hell of it out of boredom and can afford to pick and choose, then you would do well to ditch that unrealistic mentality.

 

And if you think about it, that's not really a bad thing. Put yourself in the boss's shoes. Let's say you are a project or department manager, responsible for making sure lots of people get shit done. You're dealing with people higher up than you, clients and other outside forces, etc.. you have all this shit to consider and deadlines to meet, etc. You know that the situation sucks but you pick the least of the evils and go with it. So you give your minion his marching orders.. and then he tells you "No, I won't do this cuz I refuse to do shitty work."

 

Your may try to be patient and explain to him you understand, but that's not an option. If your minion still refuses, you might have "a talk" with him about misguided principles. Or maybe you're not very patient and flip your shit over his insubordination right from the get-go. Either way the end result is the same: the only way you can "accept" his terms (even if you agree with his principle/arguments) is by you yourself becoming insubordinate to your superiors, or else going back on promises to client, etc.

 

"Oh well maybe if the boss didn't make promises he couldn't keep, or had asked me before the project started, etc.." Yeah that's fine and dandy but it's also extremely short-sighted and ignorant. Your boss receives marching orders the same way you receive them from him. He's the proverbial messenger and you're trying to shoot him, as if it's his fault.

 

Obviously everybody's situation is different. But the core essence of it is universal: bottom line is someone is paying you to do work for them. It doesn't matter how stupid or pointless or inefficient. That's not the point. The point is they want something, are willing to pay for it, and either they will pay you, or they will pay someone else. This is a universal concept. Even with freelancing. Even with buying anything in general. From the "customer's" (client, your boss) point of view, you aren't standing up for your principles. You're telling them that you refuse to provide product/service as if you know what's good or bad for them. Even if you do, it's not your right to do that.

 

It's like if a shopkeeper were to refuse to sell junkfood to fat people because they shouldn't be eating it. Well you may be right in that they shouldn't be eating it, but it's not your right to make that decision for them. It's not really even socially acceptable to advise against it, though this analogy is getting into pretty gray territory now. In reality your boss should be asking you for your PoV. And ideally, he should be trying to incorporate that in what decisions he can make, or else faithfully pass it on up the chain of command. But at the end of the day, "Do what you're told to do" almost always 99.999% of the time will trump all, so be prepared for warnings, suspensions, terminations, etc.. over it. No matter how "right" you are.

 

Which is why I will stick by it if it violates my morals, but I absolutely will happily turn in shitty code to keep my job, as long as I make sure it is understood it's shitty. People seem to always start out relationships with clients or new projects etc. with pie in the sky fantasies like it's going to be some vacation. Plan the vacation out and everything goes smoothly. But things always go wrong. Plane crashes on a desert island, don't refuse to make a fire just cuz you don't have matches. Don't refuse to hunt because you don't have a gun or a fishing pole. Don't refuse to cook because you don't have a 5 star kitchen and 5 star ingredients to work with.

[ignace]

"You either let me do my job or fire me. I don't do half-work," more often than not he will choose the latter

I don't know how employment works in America, but in Belgium when you fire someone (unless it's for something extreme) he stays on for another 6 weeks to allow him to find new employment and not suddenly find himself without a flow of income. So they are more careful before firing you because they'll be paying you while you technically no longer work there.

 

Not something that inspires productivity.

 

Also firing someone is bad for the morale which is why in most companies I've worked after someone is fired an e-mail is sent around for anyone with questions about the let-go be answered. Sort of psychological assistance. More often then not they simply re-task you. One time I've seen this was when a sales person no longer could make his quota a few times in a row was put in administration.

Edited January 26, 2014 by ignace

[.josh]

ignace .. well in America there is no such law that makes you get to work for set amount of time. So unless you explicitly negotiate something in a contract when you get hired.. the "default" legal setting is immediate termination without or without reason (unless it's for something like firing because of sex, race, etc..). Though, depending on circumstances, it's possible to collect unemployment while looking for a job. But it's fairly difficult to get and maintain it.

 

I can see what you're saying as far as it being in everybody's best interests to try to resolve shit and keep the person around, and the same can be said here, as well. It is a drain on morale for the other employees. And it will take time and effort to find a replacement and get them up to speed. So unless your insubordination causes the company to lose like millions of dollars or some shit.. you may likely "get away" with it in the sense that it wouldn't immediately get you fired. But it as you noted yourself, it will set things in motion with them to do something about it. Refuse to do the job? Okay, re-task you. Refuse to do that job too? How long do you think they will wash-rinse-repeat before they decide you aren't worth keeping around, before they decide it'd be less of a loss to just let you go? So in principle, the core of what I said in previous post still stands: At the end of the day, it's about doing what you're told.