Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Two Week Problem

openshift.redhat.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: The Two Week Problem

#21

Post by JamesLeonis »

neilk wrote: post #19

Misko Hevery (author of AngularJS) wrote a good blog post about how if you pair with a new hire for a day, you can bring them up to speed almost instantly. I tried it and it works - my new hires were committing real fixes by the end of day one. http://misko.hevery.com/2009/06/12/what-pair-programing-is-n... An additional benefit is that the experienced and more senior developer will also have to endure the pain of se…

I love your linked article because it addresses the intangibles of imparting the mental model of the code. Many times this is the delay when a new developer comes into an existing code base. While scripts and cloud tools can reduce or eliminate the configuration overhead, the programmer still needs to understand what the actual code is doing.

The last company I worked for had this problem initially. There were multiple layers of software that needed to be built and configured just so. If there was a problem with your build, it would take an hour to get and build everything from scratch if things went without a hitch. They often didn't.

This changed once we started using a build server and automated builds. This made a complete build script necessary. The benefit was that script could be used to both spin up a new dev environment (except for installing IDE and local database servers), and syncing the dev machine. Every morning I would run this script and let it chug along while I went to my standup and/or read my morning email.

I think an automatic configuration script combined with the pair programming idea, even if the programmers are paired for a day, would greatly speed up the new dev up the learning curve and allow them to be productive faster.

Re: The Two Week Problem

#22

Post by CrLf »

ecopoesis wrote: post #16

The problem is actually that most software projects are too complicated to setup. This is a kind of technical debt created by bad developers who think their job only involves coding, not maintaining the entire lifecycle of code. I bet these shops also have hard to reproduce builds and deploys that require dozens of human steps. If your new dev process isn't some close variation of: 1) Install IDE 2) Checkout code fro…

"developers who think their job only involves coding"

Definitely this. But I object to the "bad developers" part. More often than not, this is a result of the environment and not of the developer himself.

Re: The Two Week Problem

#23

Post by Evbn »

sp4rki wrote: post #10

I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plug…

Dropbox is a huge security risk for an organization with sensitive IP

Re: The Two Week Problem

#24

Post by Evbn »

boomzilla wrote: post #11
msurel wrote: post #7

It was hard for me to get past the 'two week' problem being the opening argument for this. It has never taken me 2 weeks to get any machine configured and ready to go. I agree with cmwalsh in that this drastically weakens the overall message. The only reason I continued past the 2nd paragraph is because this was linked from HN. My initial response would normally be "Who really takes 2 weeks to configure a machine??"…

You never worked with a service oriented environment, right? When you need to override dozens of services your build/local instance depends on, it could easily take a couple of weeks, especially for fresh graduates who used to "./configure && make && sudo make".

Why don't your configuration files have service client configs on them?

Does it take two weeks to deploy a build to a production machine or the integration test farm? No. Then why would it take two weeks to pushh the code to a dev machine?

Re: The Two Week Problem

#25

Post by Evbn »

agpen wrote: post #9
hoffmanc wrote: post #5

What if someone prefers a different editor?

This is the weak link imo. The entire premise is that variance in developer preferences of environments is what leads to problems, but editors are where preferences tend to vary the most. If you're an open enough shop to not standardize systems, your devs sure aren't all going to want to be locked into the same editor. In fact I'd guess most devs would be willing to sacrifice environment choice for editor choice if i…

Or provide the five or so editors all. In a Unix shop, emacs, vim, eclipse, acme, and sam, with the popular plugins the current team members use, should satisfy almost everyone to get started.

Re: The Two Week Problem

#26

Post by saurik »

lubutu wrote: post #15

I've wondered about the "two week problem" in the context of large open source projects. It would be great if a developer could spin up, say, a temporary VPS for Chromium development, the toolchain all set up and source ready to modify. I can't be the only one with a pet bug that must be trivial to fix, but the overhead of setting up a whole new toolchain to do so is just not worth it.

I was able to get Chromium compiling on my laptop (2010 MacBook Air) in a few hours using one of the tutorials on their Wiki. Most of my time was spent waiting for things to download and compile. Why would you need a VPS setup? If you want to do it in the cloud, isn't AWS enough?

Re: The Two Week Problem

#27

Post by gauravk92 »

MattRogish wrote: post #18
ecopoesis wrote: post #16

The problem is actually that most software projects are too complicated to setup. This is a kind of technical debt created by bad developers who think their job only involves coding, not maintaining the entire lifecycle of code. I bet these shops also have hard to reproduce builds and deploys that require dozens of human steps. If your new dev process isn't some close variation of: 1) Install IDE 2) Checkout code fro…

Absolutely. Development projects should have a repeatable, automated-where-it-makes-sense setup. A few things I do at my company to make sure: * give developers a new machine every 12-18 mos (depends on Apple refresh cycles). Forces everyone to install it fresh, and fix any dependency/install bugs to be fixed * all new dev hires must have it running and have deployed a change on their first day. * encourage graphic d…

What did you start using instead of Vagrant? Jc.

Re: The Two Week Problem

#28

Post by sp4rki »

Evbn wrote: post #23
sp4rki wrote: post #10

I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plug…

Dropbox is a huge security risk for an organization with sensitive IP

Well then use your own repo, or bring a usb, have it veted by IT and get your configs on your dev machine.

Re: The Two Week Problem

#29

Post by sp4rki »

rdw wrote: post #14
sp4rki wrote: post #10

I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plug…

If you're an experienced developer, but the project you join requires a different toolset and/or set of executables than a previous one, then it'll take you a good while to get up to speed on it. E.g. you've got Visual Studio the way you like it, but the new project has different code organization and code conventions and requires a different version of C++. You were developing for Android on Juno and now you're usin…

I agree that sometimes a new job might bring into light a toolset you;ve never used. I've never taken more than a day or two to get everything up to speed though. Interestingly enough, after being a unix guy for more than 10 years, my latest job required me to use visual studio. My first commit was three days after I started. This days I even have a file with all my VS configuration.

You also gave a perfect example of the only case I explicitly said you shouldn't point the finger to "new developers", which is when IT - or even the senior developers - are at fault for having a crappy development environment.

Re: The Two Week Problem

#30

Post by cglace »

MattRogish wrote: post #18
ecopoesis wrote: post #16

The problem is actually that most software projects are too complicated to setup. This is a kind of technical debt created by bad developers who think their job only involves coding, not maintaining the entire lifecycle of code. I bet these shops also have hard to reproduce builds and deploys that require dozens of human steps. If your new dev process isn't some close variation of: 1) Install IDE 2) Checkout code fro…

Absolutely. Development projects should have a repeatable, automated-where-it-makes-sense setup. A few things I do at my company to make sure: * give developers a new machine every 12-18 mos (depends on Apple refresh cycles). Forces everyone to install it fresh, and fix any dependency/install bugs to be fixed * all new dev hires must have it running and have deployed a change on their first day. * encourage graphic d…

Just curious, how was using vagrant a hassle for you? I've always found it really simple to use.
Post reply on HN