Free Advice for opinionated Entrepreneurs - when you have the right to fire anyone at any time; evaluate the person you are hiring on merit and "fit" for the role. Not based on number of past stints or time spent at each company; but mostly do not come off looking like huge hypocrites.

I think this glosses over an important point. Hiring or firing is expensive in opportunity cost (e.g. project delays, disruption to the work environment, morale) and so it makes sense to internalize that cost in a hiring decision. Suppose Person A will provide value Y per year, cost X per year, and turn over in one year costing Z. Person B produces value Y - K, costs X, but will stay for 3. If K < (Z - Z/3) all else equal you'd choose person B. Building a brand that you jump ship for better jobs ought to cost you something, even if that something is much less than the salary you gain not being a gold-watch girl.

Regardless of the source, this is actually very good advice.

I guess I'm a flake - hey, what can I say; I get bored easily and feel the need to switch projects often, especially when the project enters maintenance mode.

I also have a free advice to entrepreneurs - since I'm working remotely as I don't live in the US, I have to be much better / work much harder than US developers, just so I can take home barely the minimum U.S. salary in this industry. I also don't get any equity. When that attitude changes, maybe I'll start giving a shit.

>I get bored easily and feel the need to switch projects often, especially when the project enters maintenance mode.

Points for honesty, but I'm wary of any dev who says that. How do you know what maintainable code is if you never stick around for the maintenance?

I have heard that issue raised by colleagues during the hiring process. At the time I was suspicious about this kind of generalization, but had not been particularly sure how to evaluate the impact.

Subsequently my experience is that developers who have been in the same job for a very long time, have a higher chance of being totally clueless. And also generally not confident with new ideas, not aware of alternative ways of doing things, not exposed to the culture of the broader profession etc.

I am wary of any dev. You could go through this during the hiring process. Most programmers end up doing some maintenance even in new jobs.

But bottom line I suspect this hiring principal is essentially backwards.

In my experience, if you switch projects regularly you become increasingly dependent on your network of previous bosses and colleagues for future gigs. It's stands to reason that you will want to do the best job you can, produce the best code you can so that you have a better chance that you when you leave, you depart from colleagues that will be eager to work with you again in future.

Getting bored easily and professionalism are not mutually exclusive.

Edit: Grammar

True; but you can recognize maintainable code when working in a larger team and ownership of modules changes a lot, which it should for any healthy project.

There are several universal things you can do to ensure maintainability, which are a no-brainer, but don't happen because of various compromises that have to do with time and money - like code-reviews, having no module with a single owner, automatic tests, up to date documents / stories, etc...

If you don't do any of that, it's a no-brainer again that the project will not be maintainable; but it can still be beaten into shape later if the original devs weren't totally insane :)