Hacker News new | past | comments | ask | show | jobs | submit login

Great write-up, Jacques!

I have a question about you find such work - or possibly, how such work finds you :)

For pretty much well my entire career, since 1998 or so, I've been the guy you go to when when you something's gone wrong, and no-one knows why. Unknown codebase using an unknown language on an unknown platform? I don't know how I do it, but I have a talent that lets me figure such things out when all others have failed, fast.

It feels like this should be a valuable skill; is it simply through meeting enough people that you're the go-to guy when situations like this flare up?




As a rule the work finds me. I've been at this for very long (fixing things, working under pressure, good reputation) and that really helps.


I do similar things - DD, system repair (though I am usually much further up the stack to include product, organizational, and business structure issues), etc. Unfortunately it is often on a favor basis rather than paid.

I've been tempted several times to form the League of Extraordinary Gentlepersons or something similar. You broke it, we fix it.


That's more or less what I've been doing but informally.

Making a corporate structure for something like this hard, I came up with a model a couple of years ago called 'The Modular Company' but the bookkeeping is a nightmare if you want it to be fair.

Still, I keep coming back to it and one of these days, who knows...


I'm in an odd position of trying to form something like this (focused specifically on python development in finance). 2015 is hopefully going to be a good year - I actually have sort-of backing and if I can find time it might take off (god, just reading those caveats makes me wonder)

Anyway - I would be interested in any thoughts or traps to avoid - if indeed we are talking about the same structures.

Do drop me a line (contact details in profile)


Like in coding, complexity in a business partnership might be a warning. The book Managing the Professional Service Firm by David Meister has a lot of lessons for anyone running a traditional parter/associates firm, and the last part talks about splitting the profits. My read is that a "dumb" approach (equal split or simple seniority-based) is okay, and a "judgment" approach (publish criteria, but have a committee make the final decisions) is okay, but a metrics-based approach is risky. I agree, and for small operations I think the simpler the better. Anyway, if it's something you're thinking about, the book is a solid, meaty read.


ok, I'll do that tomorrow. 1:44 am now, bedtime for me.


Yeah, maybe just consulting? I dunno. Getting paid would be nice, I usually just have an investor-type relationship.


> I usually just have an investor-type relationship.

Then in a way you do get paid (eventually, I hope...).

> Yeah, maybe just consulting?

That's one way to keep it simple.

But there has to be a better way, especially because the nicest flowers grow at the edge of the abyss.


Then necessarily that requires taking risk. Do you want shares in the companies that get to the point where they need a your help?


That really is the key question isn't it? I can see some ways out of that and some sets of companies (not many) where that would be the case but it's going to be hard to turn them around once they reach that stage. Maximum risk = maximum potential gain, it's never been any different.


Sure. But consider adverse selection? The ones that need the help are in a different part of the spectrum than the ones that don't.


I would really love to see that, along with the occasional writeup from your adventures. (And don't forget to invite rachelbythebay, her troubleshooting posts are some of my favorite HN content.)


If you haven't read it yet this is the book you might enjoy: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.


Hmm, the book description makes it sound more like Yet Another Process Management book (e.g. "Lean ", "Waterfall ", "Six Sigma *", etc.) rather than a collection of nuts-and-bolts war stories. Is that not accurate?

I leave the process management stuff up to other folks, they're better salespeople than I am. They get paid to beat other people into submission; I get paid to beat servers into submission. :-) (Though not in Jacques' or Rachel's league.)


That would be awesome. I've occasionally done rescues and it can be really fun. So often people aren't willing to listen about organizational problems. But once you have solved some ugly, expensive technical problem, they are suddenly much more willing to consider changes that will prevent them from having the same problem in the future.

Perhaps some sort of league would solve some of the problems in doing that sort of work. E.g., the burstiness, the sudden need for specialized skills, the pipeline issues.


What is DD short for? My google powers are not strong enough...


Due Diligence?


It's also the hull class designation for a destroyer.


Due dilligence.


Old unix tool . See also ddrecue, a (couple of) nifty variation(s) on the theme.


This is true on a lot of levels. There are very few "Mr Fixits" so when problems happen, people look to who fixed the last one.

I used to be pulled into projects where the managerial side was messed up a lot. Usually the rep from one project is what would get me pulled in to the next.

An old non-technical version of this story is at http://www.amazon.com/Calumet-K-Samuel-Merwin/dp/1561141453


>>how such work finds you :)

I think you need to work towards a system and network which will help you get that kind of work. I know of a person who has worked and works only on what he considers premium projects.

One advice I got from him was to that I should think about work in terms of projects and not companies. All companies have great projects and routine 'keep the wheels running kind of work'. Your chances of ending up working for the routine boring projects even in big successful companies are very high. Plus most companies have closed allocation policies, and tend to execute critical projects from one specific geographical location.

So to look at one's career in terms which project you wish to work on, and not which company you wish to work for helps.

Another factor is to seek out and work with smart people. Once you've been a part of a good team and proven your worth and are actively seeking out good work, you are always going to find some one in your network who will get you a good project and then you use new opportunity and the new connections to get more ones.


I have the same "talent". Exploited it for a via a former employer who runs an agency for temporary contract workers, and who regularly ran into such jobs, also because he was in a network with several other such agencies.

Nice gigs, usually no more than a few days, and working with tech I had no real experience in and otherwise wouldn't encounter.

Usually very similar problems: system slows down to a crawl or completely stops working because it hits some bottleneck (often after years of working flawlessly), original supplier no longer exists. Fun things to figure out if you have no immediate stake in it.


I absolutely love this kind of work. I've been trying to think of a way to convert this into a semi-reliable job.

'Professional Troubleshooter' or something similar...


Looks like an interesting career path


It is, can't recommend it enough. You swoop in like batman & pull their bacon from the fire. Makes for good feelings all around.


I saved many projects likes this, it is work that always hunts me, because of ex-coworkers and reputation.


I've been doing a similar kind of job for last six months or so. Except that I'm doing it for everything front-end related including UX and UI design.


I really don't envy you, there is absolutely no way I could consistently work this hard for 6 months at a stretch. Consider me impressed.


At least in the video game industry (or my section), that is a typical stretch. I crunched in a similar capacity for about three years straight. The burnout level is pretty significant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: