my team is asked to build a bridge. i discuss with the team. some of them have relevant experience. built bridges before. start looking at customer needs, make sure we build a suitable bridge. management comes down. gives us an unreasonable schedule. this bridge might be a bit shitty but it should get the job done. do a few sprints, making good progress. this might actually work. management comes down. big problem. stop everything, they say. you're building the bridge wrong. they show their marketing material. it is the golden gate bridge photoshopped over the customer's dinky little canal. my team are all stonemasons. _fin_ The parable ends there but I need to get this out of my head. We push back. We can't build a suspension bridge on schedule or budget. None of us know shit about steel cables or whatever the hell. Management won't budge on schedule or features but they promise to hire a guy who knows steel cables. Our hiring process is completely fucked up. Team doesn't get to interview the guy. The head of our engineering org knows this cable guy. He gets hired. His start day is a week after our deadline. He's a total asshole. Nobody can work with him. The bridge gets built. It's a stone bridge with some steel cable bullshit propped up on top. The steel cables are not load-bearing. The cable guy couldn't work with the team. The customer is unhappy. The bridge looks like shit. They want to drive box trucks over the bridge and the cable shit is in the way. Six months later the cable shit separates from the bridge footing, collapses, and kills a truck driver. Cable guy has already left. On to bigger and better things. His resume says he single-handedly built all the steel cable shit for a bridge. While he was here he got 3 promotions and won the engineering "teamwork award" that gets you a trip to Bali. Nobody on my team got promotions or raises. Fallen below market rate. People quitting. Management telling me to convince people to stay. No raises or promotions though. Or autonomy. Or job satisfaction. Bad work environment. I try to shelter my team. Management comes to all my team meetings and micromanages my guys. More people quitting. I finally quit. Good luck, assholes.
Labels: software development
Finished Product |
"What is it?"
"Looks like an old Corellian, sir, cruiser class."
"Are we being flanked? Their main fleet came in through sector three."
"No sir, I just finished a long range sweep. No other inbound craft."
"I don't know what he's thinking, but we'll…"
"Sir! Contact is accelerating! Inbound fast bogey, sir!"
"Divert three intercepts."
"No time, sir! Bogey still accelerating!"
"What the hell! What kind of ship is she?!"
"Damn thing looks like a hunk of junk. It's still coming hard. Wait! Course correction! It's heading straight for Lord Vader!"
"Divert EVERYTHING! Get those turbolasers turned back on!"
"We can't, sir. Lord Vader himself ordered them off."
"…"
pew pew
boom
"You're all clear, kid. Now let's blow this thing and go home!"
PEW PEW
BOOOOOOOOOM
1. find a project to contribute to.
http://openhatch.org/search/ has some projects, but it is by no means
a full list. best are ones you use daily, if you can find one.
2. find the bug you want to fix by going to their bug tracker
http://flexget.com/report/1 is a typical example. this is a tiny
little python downloader and has a ton of bugs.
3. get your dev env set up. Many of these projects are on linux. I
recommend ubuntu, but some of the bugs may be platform-specific.
4. get the current dev version of the code and get it running. this
can be super fucking hard.
5. write a test and then fix the bug.
6. attach your diff to the bug ticket or mail it to the maintainer. be
prepared to explain yourself or rewrite your patch, or have somebody
else rewrite it and take all the credit.
7. update your resume.
Another option is to maintain (for instance) a debian or ubuntu package.
https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings
http://www.debian.org/devel/join/
http://www.debian.org/devel/wnpp/
with this, you won't usually write code directly on the project
itself. instead you will maintain that project's debian package. this
is taking care of the intersection of a project and an operating
system version. ensuring that the dependencies are correct in the
package, that it installs OK, that it doesn't cause trouble with other
packages, and that bugs are communicated upstream or wherever they
need to be.
sounds terrible, right? why would you want to do that? because it gets
your name and email address on the list of package maintainers for
debian or ubuntu or whatever, which is a prestigious honor. kinda.
good luck
(mailed to a friend. posted because someone else might want to read it.)
May 2004 June 2004 July 2004 September 2004 October 2004 November 2004 February 2005 March 2005 April 2005 May 2005 June 2005 August 2005 September 2005 October 2005 November 2005 December 2005 January 2006 April 2006 July 2006 September 2006 October 2006 February 2007 March 2007 April 2007 May 2007 November 2007 December 2007 January 2008 February 2008 March 2008 April 2008 May 2008 June 2008 July 2008 August 2008 October 2008 November 2008 December 2008 April 2009 January 2010 December 2010 January 2012 February 2012 March 2012 May 2012 September 2012 October 2013 January 2014 December 2014 April 2022
Subscribe to Posts [Atom]