Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Some of the things I learned at big companies:

- Process is not the enemy, inefficient process is the enemy

- Project Management makes a huge difference

- Technical people make for bad managers

- Communication is critical, ego only creates conflict, learn to pick your battles, don't sweat the small stuff: how to deal with your work and other human beings

- Perks are the last thing you should worry about

- When nobody cares, everything turns to shit

- Not centralizing/simplifying management of resources makes everything take a lot longer to get done

- Salaries are arbitrary and 2 weeks of vacation is total bullshit

- Health insurance for non-corporate people is expensive

- Unless you want to fix the same problem twice, do it better the first time

View on HN

> - Technical people make for bad managers

In my experience, it's "some technical people make good managers". Some of them are bad managers; most of them are somewhere in between.

Kind of like regular people. :)

I think the "technical people make for bad managers" idea derives from:

Companies which have limited advancement opportunities within the technical realm force technical folks with no desire for management into management positions that they're unfit for, leading to the conclusion that technical people are bad managers.

Yeah like the article states, you get to look at the complete picture and can make your own - multitude of conclusions can be narrowed to a certain subset when running a company and have a decision to make.

The company I works for has a great solution to that, it allows people that want/deserve to move into management paybands (they leave the union), but stay in their technical roles. The become managers without direct reports. Career / Pay advance, without having to take on managerial responsibilities.

Are you a Software Engineer in the United States? I've never heard of unionized programmers (at least within the Bay Area, which I shouldn't presume you're in.)

No I'm in a western province in Canada. Most government or publicly traded companies here have massive unions that represent the majority of the work force, including programmers.

Which leads to the Peter Principle: http://en.wikipedia.org/wiki/Peter_Principle

I see someone's already generalised it to the observation that systems grow until they are failing systems.

In my experience, technical skills and management skills are orthogonal. Many technical people, however, are pushed into management because there's no comparable career path strictly in technology. Organizations then pay twice: the opportunity cost of losing a good technician; and the much, much more damaging cost of a bad manager.

not to mention his salary, too

- You get exposure to big expensive technology you might not otherwise get to play with at a cash strapped startup

Sort of, there's an evil flip-side to that.

Often you end up burdened with expensive corporate-friendly technology as well as "official internal tools" which are in every way vastly inferior to open source stuff but you have to use them because that's what the company has chosen to use.

A great example in this vein is sharepoint. Other examples might be, say, team foundation as source control versus git, or IIS vs nginx, etc.

"team foundation as source control versus git"

How much experience do you have with TFS? It's a different animal than Git, but my TFS-using colleagues really, really like it.

My experience is limited, but the source control aspect of TFS seems really crude compared to git. Branching is about as hard as an old-school Perforce or CVS repository, but without the flexibility in managing your local changes that those systems allow. It only lets you keep one changeset active at a time, which can be hacked around using shelvesets, but not without occasional hiccups (TF Power Tools are often the only way to recover your work after particular kinds of operations).

I've found that every workflow I can come up with is "wrong" in some way, but none of the documentation tells me what the "right" way is. Git may have been in a similar place when it was first released, but nowadays there are plenty of good tutorials that walk you through the way to think about it.

The GUI is clunky and requires lots of clicks to perform routine tasks. For example, to view a file's history, you need to open each changeset individually and diff the file in each one. The command line is no better, and makes heavy use of the "observe something to initialize it" anti-pattern.

The main draw seems to be its integration with issue tracking, unit tests, code reviews and project management. It's trying to be a one-stop shop for everything, but the problem is that each feature has a better stand-alone equivalent. So you either lose the synergy of having one tool for everything, or you sacrifice the features that you really want from your favorite source repository, code review tool, diff utility and bug trackers.

This has become quite a rant, but I'd really like to hear a good explanation for some of these things, or at least somebody to tell me what I'm doing wrong. The worst is when somebody knowingly says "come on, it's not that bad" without actually offering a more functional workflow.

Realistically I'd have to consider myself pretty close to an expert in TFS, although I'm sure there's a ton I don't know about it.

Overall, TFS, as a source control system, is pretty decent, definitely in the top few of the best source control systems out there. However, it has a lot of downsides. It's a serious pain to administrate, and an even bigger pain to initially set up. It has a huge number of "quirks" that are really just misfeatures or defects for most users. For example, binary files are exclusive checkout by default (meaning only one workspace can have a specific binary file editable at any given time) which seems like a good idea naively but tends to bite you in the ass almost always in any real-world example. And most TF admins aren't smart enough to know how to change the setting for it, as far as I've seen anyway. Also, access control is like pulling teeth, you'd think it should be easy-peasy given that it's all GUI based and what-not but it's crazy. Similarly, things like triggers can work in completely non-intuitive ways that are really easy for, say, a moderately trained dev who's trying to be a part-time admin to screw up in ways that impact a huge amount of people very quickly (which I've seen happen routinely).

There are some nifty features, like shelvesets, and it supports a reasonable branching model with a reasonably decent merging system, though if you use it long enough you'll probably eventually run into one or another nightmare scenario that takes a long time to figure out.

For most projects I wouldn't recommend it over, say, git + github/gitlab or other free source control options. The one advantage that TFS has is that it's far more capable of handling extremely large code bases (e.g. hundreds of gigabytes of data, millions of files) as long as it's configured well, whereas git will pretty much just choke.

Also, the Visual Studio integration of TFS is pretty good, so if you use that as your primary IDE TFS will have a moderate advantage in ease of use. Of course all of this scales to how skilled you are with using source control at a low level anyway. If you're a dev who has zero interest in learning anything more than "checkout/checkin" and you hope that merges and branching and whatnot are handled by people who are not you then TFS is pretty much right at your level, it's definitely super easy to use for those common cases.

What's a better, free open source alternative to SharePoint? I don't disagree with the point but I would be surprised (and interested) if there was a open source alternative that compared to SharePoint.

Have a look at Alfresco.

Also, see my question to parent.

As an aside, what is the 'vastly superior' FOSS alternative to Sharepoint? I've looked at Alfresco, but it was a pain to install and configure.

Also, it doesn't seem to be 'true' FOSS because we get access to dirty HEAD code and not the code they use for the 'enterprise' version.

They further refuse to commit the name 'stable' to any of the community versions.

>- Process is not the enemy, inefficient process is the enemy

corollary : efficient process doesn't exist

Contradiction: Efficient process is automation.

> "Salaries are arbitrary and 2 weeks of vacation is total bullshit"

Could you expand more on what you mean by the vacation stuff? Do you mean like it's total bullshit that you only get 2 weeks? I was not sure how literal to take that.

It takes about a week to prepare for a vacation and about a week to recover. Trying to fit "okay, everybody: three, two, one, FORCED FUN TIME" into short time periods is more annoying than entire trips are worth.

Companies strip away between 1/3 and 3/4ths of your personhood (depending on the person) and autonomy in the world.

Try not to get stuck.

I suspect that's what he meant. In a small company two weeks is often all you'll ever get, if that much. In a large company you'll start there and pretty quickly get to three weeks, and if you stay long enough you'll get to 4-5 weeks.

This is in the US, of course. In a humane country you start with 3-4 weeks, and I think after a couple of years in some European countries you get around six months of vacation per year ;-)

I work for a University, and albeit having a slightly lower starting income than some private industry, my starting vacation time is incredible. I accrue just about 2 days per month paid vacation time. Besides regular holidays, I also get school holidays off too. 10 work days for Christmas paid. 5 work days for Spring Break paid. And I get 1 full day of sick leave per month that gets accrued too. It's fairly gravy.

I make iOS apps, and contribute to fairly large state-wide systems. Besides rote governmental/enterprise work, I also get to fool around and make interesting things because my role is also technically a "research" position. Did I mention I see/talk with my supervisor about 4 times a month, and he trusts me totally?

All that's awesome and everything, but there are downsides too. I am considered Junior, and will be for the next year (been there a year already). I make less than some of my coworkers despite being able to code circles around them (and architect systems better). Others are really, really damn good, so that's not always the case either Part of the problem is my degree - I have a Bachelor's in Art (of Arts too, but you see my point). This means that I'm fixed for at least the next year below my actual value, which sucks. My direct coworkers on the Mobile team are awesome, my age, share liked interests and we share a camaraderie that is probably absent at a lot of big companies and startups alike. Tradeoffs abound, but personal happiness and autonomous professional development are what I'm taking for the time being.

Don't sleep on BigCo or unusual positions just because it isn't sexy startup land in SV. There's a whole wide world out there too.

You need to work at better small companies.

My company is pretty good about vacation time, plus flex time whenever I need it. I was generalizing.

I started on 29 Days leave at a UK FTSE 100 company.

I didn't write that, but my guess is that it was literal.

I've seen and personally worked at a company where 2 weeks was not only your vacation time, but also your sick time as well. A government contractor I had worked for gave out 4 weeks (which was also sick time). Currently, I'm at 3 weeks.

Most places use vacation as an incentive - stay with us x number of years and we'll give you another week of vacation. I personally haven't stayed at a place long enough to realize that benefit.

This always seemed weird to me. Like, you can be a senior software developer with 15 years of experience, and if you get hired at a new company they'll only give you 2 weeks of vacation to start? Really?

It's a negotiation point.

> - Technical people make for bad managers

But who makes for good managers?

Good as in pleasant, or good as in effective at launching great products?

Good as in effective at managing people - more specifically in this case, at managing technical people.

Reply on news.ycombinator.com