Good Developer Idea: As part of the open culture at a struggling SaaS startup, you give a developer the admin rights to your build and deployment servers.
Bad Developer Idea: You forget to eventually take those rights away when you go into production, and when the Feds come to raid your offices, you learn that the developer has used your servers to host a “Man Seeking Horse” dating site. (Even after you elaborate on how horses can’t use computers, the developer still stands by his idea.)

Good Developer Idea: Create a library that has reusable, generic code for your group.
Bad Developer Idea: Let the least-qualified lunatic in your group take ownership of it and ruin its whole purpose. “So, with the latest changes, you pass your name into the class constructor (like “John”), and the class executes only your code instead of the code that was written by you or Bob. See? It’s shared and reusable. Now leave me alone to snort my lines of molly.”

Good Developer Idea: Writing to log files from your UNIX program or script.
Bad Developer Idea: Porting that program or script to Windows and still writing large log files in the years B.C. (Before Cygwin). On the plus side, when you opened a 100MB+ file, you gained another hour of personal downtime for yourself.

Good Developer Idea: In order to demonstrate a particular method or style, share a project with one of your junior developers/admins and let them use it as a template.
Bad Developer Idea: Forget to stress that the variables in the configuration file are not supposed to stay the same. “Thanks for letting me use your project. Look! My new project ‘PurgeTableData’ works! What did you say about database properties in the config file? More importantly, what’s a config file?”

Good Developer Idea: In the face of a new project being discussed, you argue against the suggestion of an off-the-shelf proprietary technology that doesn’t really fit your company’s needs.
Bad Developer Idea: Even though you may be right, they press you for an alternative, and you don’t have one. Consequently, you are forever known as ‘the whiny bitch’ among your peers, and they force you to wear a burqa in the office as a reminder.

Good Developer Idea: When attempting to find a new candidate for your development team, encourage other developers to be a part of the hiring process and to provide input.
Bad Developer Idea: Not using discretion as to which developers that you encourage. “Okay, so I would eliminate the first guy, since he puts the opening bracket on the same line as the function declaration. Only idiots do that. And the chick…well…we know chicks can’t code. So that leaves the weird guy who carries around his dead, taxidermied daughter. Now that guy can code! I would pick him.”

Good Developer Idea: Working with management, you help to eliminate the method of stack ranking your fellow employees, ensuring that each one is evaluated on individual merit.
Bad Developer Idea: You forget to take into account that they are all essentially worthless, and based on the new system, they are all fired. In turn, they find out where you live, and they burn your house down.

Good Developer Idea: While at Scrum meetings in the company conference room, you use the whiteboard to create a visual map of the next iteration in your project.
Bad Developer Idea: In order to make room, you clear the current board in haste, and without thinking about it, you erase the cartoonish doodle in the corner of the board. When the CEO and his 6-year-old come to the conference room later (so that the kid can proudly show the doodle), the kid erupts with tears. In order to make amends, for the rest of your life, you must now give the kid and the CEO a piggyback ride whenever the both of them are in the office together.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.

1.) Convince investors from a third-world country that a mashup of MailHooks and RequestBin is going to replace texting in the near future.

2.) Start to create JSFiddle examples as substitutes for your blog posts and convince hipsters that “they need to catch up”.

3.) If you own a company, use Mirrorrr to pull down and create an exact replica of your competitor’s site, except for the added endorsement of NAMBLA on every page.

4.) When that asshat down the hall wants to “inspect” (a.k.a., “copy”) your code yet again, be sure to be a team player and give it to him…just be sure to run it through UrlEncode right before you do. If he asks you about it, tell him that you’re “l33t” and that’s how you code.

5.) Recommend HostTracker to your less tech-savvy relatives, telling them that it will protect their Facebook page like a junkyard dog and will call the cops on anyone who unfriends them.

6.) Install Fiddler onto the computer of your boss without him being aware. One day, launch it and proceed to convince him that it’s a monitoring tool planted onto his machine by the NSA. If he just gives you $20K, a gun, free hardware, and 2 months of vacation, you’ll be able and willing to put a stop to it.

7.) Play pranks on friends, asking them to help debug HTTP Posts which come to your web site. Using MailHooks, make sure that any Post ends up calling emergency services, so that your friends end up swatting themselves.

8.) Reroute your network configuration so that all addresses point to Necrohost.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.

Some people are advocates for the extended participation of stakeholders when it comes to implementation, but I would advise caution against that. Why do I say so? Because like some others, I’ve seen the results…

Let’s say that your company has a plan to eliminate the redundancy of existing data in several departments, by creating one schema which is to be shared among the many. After several weeks of collaborating in a state of perpetual confusion, the stakeholders of your project have met on their own without you (despite your repeated warnings of violence towards them). Together, they have stupidly consolidated their tables of sewage and finalized the schema for one massive failure that they plan to share:

Product Table

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.

1.) If you list “Software Engineer” as a job title, there should be examples of actual engineering listed somewhere. “Got Visual Basic working with Excel spreadsheet” does not count as software engineering…nor does that really count as programming. It’s a thin argument to even place that in the category of “software”.

2.) If you’ve worked at 7 different jobs over the past week alone, you might want to manipulate your résumé so it isn’t immediately apparent that you’ll cut out at a moment’s notice.

3.) In your list of technologies with which you are familiar, please refrain from mentioning tools which have lived long past their use or relevance. Nobody is going to be impressed that you used Windows 3.11. You might as well mention that you played a Sega Dreamcast at one point and that you’re fairly sure one of your ancient ancestors used a wheel before it became popular.

4.) If you’ve worked in the technical field for more than ten years and if you graduated much longer ago than even that, there really isn’t a need to mention the school. Plus, if you graduated in Asia and are working in the U.S., it’s completely ignored. (In the case of IT, most IT managers won’t even know the school that you’re referring to, let alone tie their shoelaces by themselves.) You could put down that you have a Master CPU degree from Kali Ma Shakti De University in Pankot, with a minor in archaeology…and nobody will be the wiser.

5.) If you want to highlight your strengths (such as your ability to work with teams and your keen meticulousness), you should present yourself in such a way as to demonstrate them. Writing “Excellent communikation skills and very talented at talking” actually works against you.

6.) By default, all of those who don the hat of a technical screener (like myself) assume that every candidate is going to naturally present himself/herself in the most positive of light. Having said that, if I see another résumé with the phrase “great team player”, I’m going to actually play baseball with a candidate’s head by introducing it to a Louisville Slugger.

7.) Since you’re supposedly a qualified worker in the technology field, your résumé should naturally be prepared with a certain amount of technical finesse. When your document is presented with an heterogeneous mix of Arial, Times New Roman, and Verdana, it doesn’t inspire confidence in potential employers when you can’t even slay the dreaded monster of Font.

8.) Please refrain from boring the living shit of the person reading your C.V. by filling it with nonsense. Since I assume that you have used a keyboard at one point as a peripheral device and that you went to a meeting where you talked to people (in order to “brainstorm”), you do not have to write those activities down. I also assume that you didn’t defecate in your pants one afternoon, using your new cargo to write your name on the lunchroom wall…but you don’t need to write that down. (To be fair, though, I would enjoy reading that if I stumbled upon it.)

9.) For software developers and engineers, one way of showing your proficiency with abstractions is to demonstrate the summarization of data. So, when you list 20 specific projects that have an overwhelming overlap in functionality, you’ve shown me that on top of not being proficient, you are likely mentally disabled. I don’t care if you have “created a back-end that supports the front-end” twenty times in different scenarios. If you list it more than once, you’re an idiot.

10.) If you claim to be a writer of technical documentation but you’ve only used three verbs throughout your entire résumé (and I’m betting that those words are ‘developed’, ‘designed’, and ‘analyzed’), then you probably have a better chance of impressing me with illustrations drawn in pen and crayon. Remove that part about writing good technical documentation, and we’ll accept your possible employment with the footnote that you’re an illiterate simpleton.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.