Hacker News Reader

Comment by bikamonki | Hacker News Reader

More options: - Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use, with new features and support contracts you will have steady income for the long-term. - Go startup. Stop thinking you need to come up with the next über-for-x. There are plenty of opportunities for small sass shops that cater locally and provide sufficient income for a micro successful business. At worst you'll be acquired. - Go sidetrack. I read someone said every business is a software business. Start a different career/business and you'll be doing the IT needs yourself. That alone is a huge competitive advantage.

These options allow you to continue programming after 40 and you should! It is an urban myth that past 35 programmers are not as good b/c they get tired faster or make more mistakes? The truth is that 20-somethings can put up with very long hours b/c they have the time (mainly due to not having a wife and kids) while 40-somethings have the experience to go right to the answer. That's productive vs efficient. I like to use a soccer analogy: a young defender is good when he's fast because he can outrun the attacker, while an old and slow defender is better because he knows where to stand and wait for the attacker. Experience is gold.

View on HN

I'm over 40 and I've always worked as a consultant. Until recently I was the sole developer on a site doing eight figures in revenue (now I'm team lead). Without being arrogant here, if my skills match but someone doesn't want my level of experience, it's not a good sign for the someone.

On the flip side, I would love to throw out all of the languages and frameworks I've been using for the past few years and learn entirely new tech. That's part of the point of being in this business!

If you're a startup and have a bias against us greybeards, you're only hurting yourself. We'll learn your framework-du-jour and tell you how it bears an uncanny resemblance to something that didn't work so well in the past. Or maybe we've never seen anything like it, in which case we'll be delighted to cast aside all that old crap.

I usually summarize this thusly: "I have already made the mistake you are about to make". It should be obvious the time savings would worth it to "rent" me. And I am months away from my 40th birthday.

It's funny you should say that. A few years ago, at a company whose name everyone here knows I, an old gray-hair, almost lost my full-time job for warning a VP that she was about to make a mistake I'd seen before. I honestly thought she was joking when she told me about the approach she was going to use to deal with a "hard deadline" of four months. I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan. She became indignant and ended our meeting (just the two of us), getting me transferred for "not being supportive of the team" and trying, unsuccessfully, to get me fired.

She gave the job to her three dozen "supportive" young programmers, who ended up taking 28 months (!!) to get the "4-month" project finally working.

So, after all that, did she eventually apologize and tell me that, yes, she'd made the same mistake I told her I'd seen before with the same results for the same reason, and that she should have at least asked me more about it instead of throwing me out? Of course not. This is the real world. She never spoke to me again and never forgave me.

Pretty sad story ... I observed this kind of scenario myself :/

To be honest, I don't find it that surprising. Being laughed at is not something people take kindly to. Of all the possible ways of letting her know that you thought her plan sucked, that was the one that was doomed to fail right from the start.

An experienced and mature manager might appreciate the frankness.

You can be frank without laughing at it.

For sure. Don't be a dick is a pretty good strategy. However, I didn't get the impression that was his intent though: "I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan".

Right. I was neither being "frank" nor intentionally laughing at her plan. She was smiling, and I thought she was kidding. I was smiling, and she apparently thought I was approving. Suddenly, we both realized we were wrong. Oops.

At that point, the damage was done. I tried to explain why her approach of changing N things simultaneously wasn't more efficient than changing N things sequentially because of the combinatorial explosion of interactions, but she wasn't technical enough to understand what I meant by that, which made her angrier, and when I suggested an approach that would give us a temporary "Plan B" just in case we "ended up a couple of weeks late", she declared me "unsupportive" and ended the meeting.

Holy shit dude, living this now. The pain in terms of support and phantom, impossible to reproduce errors will go on for years.

It was a failure of communication. Even before analyzing why or what happened, a failure of communication is something that arises out of actions of both parties and even the prevailing culture of the team.

Nobody really likes it, but half of the "politicality" of management has to be set in place to allow people to communicate with others who may or may not suffer from a sensitive ego and the company hasn't had time to figure it out yet. On top of that, it's usually a judgement call and may be a poor idea to formalize into your process an escape hatch based on judgement.

So maybe the original mistake was from the manager who presented a sensitive idea without enough seriousness to induce a careful response. Or the op who was too quick to feel comfortable interpreting it as a joke in what turned out to be a serious meeting. Or the culture which enabled the terms of the meeting to be ambiguous to begin with.

Only after that can you get into things like speculation on the maturity of the manager. It's actually quite a high maturity bar to jump over to stomach being laughed at by an expert. Not saying you can't set that as a goal, but merely that you ought to think about what happens when you find yourself dealing with someone who hasn't met that expectation.

I try to always write minutes from meetings. Sometimes I also send them out. Other times I just store them somewhere that has 3rd party timestamps (dropbox or googledocs).

Maybe you should consider that, as a grey hair, one of the skills you should have picked up along the way is how to behave when talking to a VP.

My reading is that he wasn't laughing at her plan intentionally. Her plan was so bad that he thought she was joking, and he tried to be polite by laughing at the VP's joke.

There's nothing wrong with him. As I wrote above, as the brain ages, you get more experience and depth and foresight. The problem is that the decisions that use these abilities don't belong to programmers - they belong to managers (in this case the VP).

This is one of the main recipes for perennial frustration - be an older programmer trying to act like a manager from the bottom of the hierarchy.

The interesting thing about engineers is that they have very little tolerance for these destructive social shenanigans. Courtesy and politeness are one thing, but ignoring such a flagrantly flawed plan goes beyond courtesy and into professional negligence.

When empirical thought is your bread and butter, as it is in the case of software developers, it's hard to see why you should have to acquiesce to the VP's ego. If one intentionally stays off the political tracks, there really is no reason they should have to play unreasonable political games. Workplaces would be much more efficient if we accepted, or at least heard, the advice of the people who get paid for their expertise, instead of cowering in fear that we may damage the ego of some fragile soul who ended up in management because they were not competent to do any real work directly.

YMMV, but what one perceives as 'unreasonable political games' is highly personality-dependent. Most people have some set of behaviors that they find appropriate in some situations but not in others. For instance, wearing sweatpants to a wedding is generally frowned upon, for reasons that have little to do with their ability to maintain the body at a reasonable operating temperature. You can wear them anyway, but then you get to face the social consequences of doing so.

It's true that workplaces would be a lot more efficient under the regime you describe. It's also true that if my aunt had a dick she'd be my uncle. I'm suggesting that it might be a good idea for engineers to do the same thing as everybody else in the world and try to figure out when to wear sweatpants.

This is not anywhere near as socially tone-deaf as "wearing sweatpants to a wedding" -- it's more like showing up in a tux when everyone else caught the note on the invite "ironic dress only, please wear trash". The situation the parent described was the presentation of a plan of complete absurdity, which he advised against after realizing it was serious.

I agree with you that developers would be well-served by making a stronger effort to play along with the superficial niceties of corporate politics, but like I said, this transcends that and gets into a professional duty to advise against. If the workplace is so corrupt that reasonable opposition to a blatantly silly implementation plan can only result in the correct subordinate getting shuffled around and possibly fired, it's a liability for professionals to continue employment there.

I am now convinced that an idiot in a management position is unable to raise himself above the level of idiocy he is in - by any means. By definition, he should have to _listen_ and _weigh_ the facts being reported to him, not only to filter out the hidden agendas, but to also see all the facets of reality. Doing this would automatically exclude him from the idiots group.

Unfortunately most of management ones will not tolerate unaligned lower ranks and are unable to utter the words "he may have a point" to themselves and regroup and refocus.

Instead they will do whatever is necessary to remove the opposition.

See the Challenger for recent high profile examples.

Did you mean "or" not "for", or are you an old fogey who forgot that most of HN wasn't yet born when Challenger exploded?

You made my day. I meant "for" but indeed time is relative. I was 11 at the time and Challenger event is "recent" to me even now. Maybe because I was into stars and rockets and a friend showed me a newspaper cut with Challenger launch a year before or so.

Blaming the victim.

as you allude to in your final paragraph, the unfortunate reality is that unless you're specifically assigned the task (in this case, the VP was), it's not your role to dictate the plan or criticize it to the level you did. at most, you can make your observations known once. this sort of thing very rarely ends in termination or quitting, but usually a sort of political/social alienation which you describe.

in reality, your only two options are either quit, or be the VP. as a non-executive/manager, you don't run the show, end of story.

Successful technology firms are not run the way you describe.

HAHA, what? yes they are. what you're saying is that the at successful companies, individual contributors never get upset at the direction/architecture/decisions the executives and project managers choose - okay buddy.

You should quit working for her. Either transfer to another department or if it is not possible - transfer to another company.

There is almost no upside working anywhere near her. She would screw up every meaningful project and attach failure to professional reputations of everyone involved.

What was the approach she was trying to use to deal with a "hard deadline"?

I can't give away too much here, but we had bought some companies and had to change our Web stack to show that we ate our own newly acquired dog food. That part was unavoidable.

I just assumed we would make a gradual transition, replacing the two stack layers one at a time, and starting each of those replacements with new, non-strategic web apps (ex: a mailing list signup sheet for some small event), always getting things working before extending the rollout. We would get as many things working as possible by the "hard deadline", and our customers for these new products (who would be developers themselves and would know that these were new products for us) would understand that a gradual replacement of our old technologies was just good engineering, not a sign that our new products weren't good.

But she told me with a smile that we were going to replace all of our Web apps simultaneously with a matched set of replacements showcasing what could be done with our new products (one of which would require using a version so new it wasn't even feature frozen much less production-ready, to show off our coming features) and, as long as we were changing two critical layers of the stack simultaneously, we would change all the other layers, too, right down to the OS and hardware "and just do it right".

And I assumed I was just laughing with her--yeah, yeah, very funny--until we both suddenly realized what was actually happening.

(And, I don't work for her. I was transferred elsewhere, and she was eventually laid off.)

Did you grow the site into 8 figures or brought on board? What was the site doing? I would imagine management would be terrified of reliance on one, bus-getting-hit-by developer.

You'd be surprised how cheap or short sighted managers can sometimes be. I guess from their point of view they might see a developer as overly expensive and dogmatic.

I've seen companies with 7-8 figures and reliant on just 3-4 devs with unique and non overlapping abilities. It's more common than you think!

I developed the site entirely. To be clear: The site is essentially the interface to the business. I won't say I developed it "myself," since I was in a team with non-technical people who knew what functions they wanted from the site. However I was the only technical person involved.

Now we have more developers, for which I am very thankful. Unfortunately, way too much knowledge is locked up in me, and I never have time to commit that knowledge to bits, paper, or oral history.

Believe me, buses and beer trucks have been discussed as possible ends to my consulting gig. It is my fondest hope that this business has key-man insurance on me. I'd be pleased to know that they have such insurance, but less interested in knowing how much the policy is for!

i'm still trying to figure out whether to learn ruby on rails or play2 scala for web development, what do you suggest?

You're not asking me but I'd go for the one that you're likely to be least familiar with, that will teach you the most.

Having worked with Ruby on Rails in the past and with Play2 and Scala currently, I think I can answer that.

For your regular web app, both frameworks are mostly the same, both are boring - Rails is more productive for very common tasks, but Play2 is safer because of the underlying language (well, if you pick Scala, otherwise Java just stays in your way). Things get more interesting in Play2 when scalability or latency starts to matter.

That's when you discover that Play2's architecture is entirely asynchronous and that Play2 supports asynchronous responses and web sockets natively. It does so by means of futures [1], actors [2] and iteratees [3] (also being migrated to reactive streams [4]).

Of course, the easy route with Play2 would be with Java, however I recommend that you pick up Scala. By doing so you're going to get exposed to concepts from functional programming in a language sitting on a platform that's very much practical for real world use. There's also this book on functional programming in Scala that's amongst the best books written on the subject [5]. Functional programming changes the way you think and it's all about sanity, functional code being easier to test, being easier to parallelize and being much less prone to accidental bugs.

But while you're at it also consider learning Haskell, probably the best functional programming language available, because even if you're not using it, it's currently the lingua franca for FP concepts, so when reading papers and blog articles on interesting design patterns related to FP, most of them are described in Haskell. It also spoils you with its incredible type system, so a language like Scala will become the minimum that you'll tolerate, working in Java, C#, Python or Go becoming unbearable ;-) A really good beginners course is this one from edX [6]. And then go learn Clojure, because it's a really practical LISP that is also oriented towards FP, except that FP in a LISP is really different from FP in static languages like Haskell or Scala.

And you know, the best thing about this path is that you're not going to learn just a framework, or yet another language, but you're going to learn about functional programming, which is a concept that transcends programming languages with its related mentality and design patterns and is useful no matter what you're doing and in what language.

But then going back to Scala and Play2, well that's useful right now too. And did you know that Scala compiles to Javascript too and it's awesome?

[1] http://docs.scala-lang.org/overviews/core/futures.html

[2] http://akka.io/

[3] https://www.playframework.com/documentation/2.3.x/Iteratees

[4] http://www.reactive-streams.org/

[5] http://www.manning.com/bjarnason/

[6] https://www.edx.org/course/introduction-functional-programmi...

[7] http://www.scala-js.org/

In all honesty, I'd recommend the use of Erlang alongside a framework like Chicago Boss, N2O or Nitrogen over Play if you want the actor model concurrency, default asynchronicity and WebSocket support. It simply supports these ideas in a way that Scala cannot compete with, alongside its concurrent error handling, the OTP framework, location transparent distributed nodes out of the box, binary pattern matching and so forth. Issues of typing aside (success typing is still impressive), it is a much cleaner and more FP-focused language than Scala's chimera paradigm.

The actor model for concurrency is rather poor depending on use-case. I prefer to mix and match approaches. I mean, modeling concurrent state machines, with bi-directional asynchronous communication that makes you easily lose sight of how data moves in your architecture, what could possibly go wrong?

And yes, it's a pretty good model for concurrency, however I consider it to be a compromise on the way to finding better approaches. And in the meantime, it just feels wrong to use a language that forces this mentality on you, unless you have specific use-cases for which this model fits perfectly that is.

And also, on the FP side - many people say that Scala is less FP than other languages, like Erlang. That's a rather odd assertion, because my experience has been the opposite. But that's for another discussion.

Write a trivial app in both. Use your own judgment to determine the best tool for the job. It is entirely possible that the best tool will be neither of these!

The website in question is written in Ruby on Rails. Since v1.0 (and Ruby 1.8). And it is now on current Rails (and Ruby!). Rails is a moving target, to put it mildly.

If I had to render an opinion, I'd say I love Ruby. Rails I tolerate. Some parts of Rails are great; others are tedious. By its own admission, Rails is opinionated software. You may or may not share its opinions.

A novice doesn't know what tools he need. An expert has mastered the tools he has been given. A master starts thinking about the tools he COULD have :)

I will get downvoted for this, but have to do it anyway:

NPM either disproves your thesis or has an exceptionally high amount of masters in its community for a language at that level of abstraction.

I absolutely agree. Over the years I've worked with many sharp guys that are 50+ and their experience always commands massive respect from me. People who dismiss the more experienced segment of the workforce are, to me, absolutely, inexcusably incapable of critical thought. If all one sees the glitz of the young guys at TechCrunch Disrupt and concludes that they're the only talented devs out there, I want nothing to do with that person in a professional capacity, to put it plainly.

The main problem with hiring grey beards, as you put it, is that a lot of them aren't amazing, but due to years, they have an authorative attitude and expect to be paid more than your 20 something devs. If it's my money, I'd hire the 20 year old with gaping holes in their knowledge who are willing and eager to learn over the 40s something dev who thinks their way is better because they're 10 years my senior. I have a lot of anecdotal experience where I've rejected folks who were lacking a basic understanding of the pro's and con's of something. These guys aren't rejected because they don't understand the subject, but because they fail to accept there are scenarios where doing something the other way is better, or that at the very least, things at a bit give and take. This, I postulate, is generally because these guys have 10 years of 1 years experience, rather than the experience they're trying to sell themselves as having. These are the type of guys who will struggle when they're older. That said, when it comes down to it, most of the guys I try to hire are older than me. Age isn't a deciding factor, they just tend to be better.

Something that really frustrates me is people who are more expert than me but can't justify their pronouncements. I had a high school friend who I'm sure was smarter than me claim, "No one does object oriented programming the right way [except him]," but when pressed would just deliberately play games and mystify. Most DBAs I've worked with had their preferred way of doing things, but were incapable of answering Why? It's not easy working with these people. I've come to really value a colleague who can teach---that is, who can explain why they choose what they do.

I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.

2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.

And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.

Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.

That's actually a cracking point. I want to work with people who can defend their positions. The reasoning behind our decisions should be clear, if it isn't, you lose points against the guys who can do it. Luckily, age typically makes you better at this, which is what makes it really suspect when you get an older guy pulling an appeal to authority.

This is a great point. I try to get people to argue stuff on technical merits, and it's surprisingly hard to do. An example I work with now is the guy who bad mouths sql, non stop, and also promotes nosql non stop. He can't compare and contrast the two, even in general terms. Makes it impossible to have a discussion with him.

I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.

"with gaping holes in their knowledge who are willing and eager to learn"

If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.

I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.

Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.

"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".

Did you bother to be honest with them about why you "rejected" these folks?

I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.

Hi there, you seem a tad upset. You should probably note my last sentence where I point out most of the better folks who I want to work with are older. My point was that simply being older doesn't make someone better, and that I'd rather train a junior than deal with a stubborn incompetent senior team mate. Unless you think the latter applies to you, you probably shouldn't be upset, I'm not generlising, I'm pointing out that if you're good, you don't need to worry.

That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.

"and that I'd rather train a junior than deal with a stubborn incompetent senior team mate"

I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").

I'm not upset at you.

"I'm pointing out that if you're good, you don't need to worry."

Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.

The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.

It's actually not a case of fearing there are people who are difficult to deal with, I have absolutly no doubt you've experienced people who are stuck in their ways have as many hidden costs as the junior. I've taken over from older devs who don't use version control, nor a dev environment, refuse to use frameworks or follow coding standards. Should we honestly believe they don't have hidden costs? Would you really rather deal with them than train a kid?

Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.

> More options: - Go solo.

As someone who has been 'solo' for a very long time, I have to heavily disagree with this opinion. Going solo isn't as simple or easy as what the OP seems to be implying. Going solo means you are essentially working two jobs at once as it takes a tremendous amount of work and dedication to network, find good projects and keep them rolling in to pay your bills. To further exacerbate things, each year the amount of competition that you face ramps up drastically as more and more workers enter the consulting world who are unable to price themselves correctly and are willing to work for less and less.

Furthermore, by going solo, you are now assuming 100% of the risk as to whether or not your new consulting business sinks or swims. Chances are, just like any start up, you will sink. Additionally, you will have added burdens such as insurance requirements, self-employment taxes, various state/county-level taxes (such as gross receipts taxes) and a laundry list of day-to-day operations that you will need to perform that aren't related to software development.

Going solo really isn't for most people and I wish we'd all stop perpetuating this myth that it is somehow easily attainable. Remember, a solo consulting business is the easiest business you can start, maintaining one is the most difficult business you can run.

> Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use,

someday i might get there.

> At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame

At 25...

I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.

The time limit is not age but how much experience one has doing software engineering projects. One needs several unders ones belt, preferably some that have actually shipped so that one sees what the end user implications of the said products are. How long this will take? A couple of years? Hard to say.

>I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.

How did it work out for you? I am curious as I am thinking of shifting from fin. applied math (econometrics) to SE ...

For me it worked pretty fine careerwise (I'm now 35 to be precise). I'm working now in the technology development department of a multi-discipline CAD vendor, everyone else is really talented and I mostly enjoy my tasks. I even get to write simple linear algebra like a QR decomposition now an then. The job is stable, mentally stimulating and my co-workers are sensible human beings - who are mostly way past their 30s and some over 50s.

I turned to software engineering because computer graphics gave and give me such a huge kick. I don't know what intrinsically motivates you so I cannot comment whether I would suggest the career for you or not. Here's the rub: software engineering can be viewed in some circles as blue-collar work, which means the work environments can vary quite a lot. Also, the discipline is really young, and it shows in the amount of cargo cult and bullshit quotes one finds peddled as "best practices". There can be gigs where co-workers are experts and those can be great, however, there can be lot of environments where co-workers are perpetual expert beginners and those can suck big-time (or so I've heard).

Realistically, software engineering is still a pretty solid career choice so from a sustenance point of view I'm sure there are far worse options one can choose.

If you graduate at 21 and start working immediately, by the time you're 25 you'll have 4 years of experience with a few shipped mid-size projects under your belt. It's not that uncommon.

Define mid size. The only reason I ask is that at 4 years experience I had no where near the skills I needed to lead a midsized product.

At 25, you should be working towards a goal to not having to do anything to make make a living by the time you are 40.

Focus on eliminating the very need for the problem to exist. Than on workarounds.

Latex's author already prove it wrong http://en.wikipedia.org/wiki/Donald_Knuth

Prove what wrong?

I think comp1927 means Knuth proves that one can get better with age. Which is a fine point, but Donald Knuth is a difficult lead to follow.

Keep in mind that Knuth is not a software engineer - he makes his living as a tenured professor at Stanford (these days professor emeritus).

I grant your point, but that's a bit like saying Einstein was a good physicist.

Knuth did TeX. LaTeX was Leslie Lamport. LaTex is short for Lamport TeX.

Quite the exclusive clique they've got there.

The problem with age is you become less flexible. If your have a business where you know what you will be doing in 6 months time then experience is great - when your plans change weekly then the flexibility of youth is what you want.

Define "less flexible", someone doing consulting has flexibility to pick and choose clients. Someone who continually learns is capable of picking and choosing technologies. I would think even someone in their twenties would have issues with "plans changing weekly".

Less "flexible" with salary and benefits, presumably.

I've known people with nest eggs happy to take cuts for something interesting.

But I also know with experience comes a skeptical eye for being asked to carry extra load for less upside (yet same or more risk).

A story from some time back told to me. Founders had a UI, an algorithm, and an idea. It had merit. They sought someone out to build and run the actual service. The funding was angel, the role was senior to C-level, but the salary offered was 40-60k cut for a senior engineer at the usual suspects, equity capped at 4% assuming a trade off in salary.

Risk and reward to build out infrastructure and productize someone's idea? I could certainly get a couple of people to build it out in a "get us to a-round funding" in those guidelines, maybe even beyond. But as expectations on a non-founding senior/early member, one would assume way too much risk for the potential upside.

It isn't non-technical founder seeking technical co-founder waters, but damn close.

Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.) I once did, but will no longer tolerate that crap from an employer.

But being older doesn't mean you stop learning, adapting to change, or lose the ability to deal with moving targets. I'm hopping rapidly between roles and widely varied tasks at my current gig better than I would have in my 20s or 30s since I've got more perspective and experience.

A more mature person might point out that if your plans change weekly you likely have a systemic problem, though, and would be more likely to point out the breakage.

>Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.)

This stuff is a false economy anyhow since it inevitably leads to a massive ramp up in technical debt even with the very best programmers.

I am not a young developer, yet I recognise what it is about youth that is attractive to employers. This is reality and I don't think there is anything to gained by pretending otherwise.

I am not suggesting that you don't have a problem if your plans change weekly, but unfortunately this is the way many businesses are run. When you have a very fluid workflow youth is very attractive.

> When you have a very fluid workflow youth is very attractive.

i.e. you don't bother to spend an hour to plan a project. I don't think anyone wants to work at those kinds of places, young or old.

It is not a matter of planning, but of adapting to change. I have worked in environments where change occurred regularly (outside forces at work) and I saw it was the young who coped with this change best.

I would need a concrete example but I'm not buying your assertion. Some of the most flexible people I know are all developers, irrespective of age. If you told me that older developers were more likely to ask questions and seek evidence before making a change I'd believe that. I find that most people confuse easy adaptation to change with pliability due to lack of experience.

I've seen the exact opposite. Startup, pivoted 3x in 3 years. The younger devs have a much harder time accepting he pivot and figuring out how to adapt. So without any more substantive evidence, my experience definitely refutes this silly argument that youth is more flexible.

> The problem with age is you become less flexible.

For those who use their minds, which should be common in this field, those effects become noticeable much later in life. For most of the working lifespan the dominant effect will be an increase in experience.

I'd say more generally, as someone in their early 30s, that my experience says that if you're changing the plan weekly, the problem isn't with the employee, flexible or not.

In general, if the plan is changing every week, that probably means that the work I did last week was mostly pointless. That's a great way to burn someone out.

Good news though! I do contract work, and if you insist on changing the plan every week, you won't need to worry about whether I'm flexible or inflexible. I'll happily fire a client who can't make up their mind and thinks that the best path is to change direction every week.

This is all true. It seems to have been missed in my comment this is not my view, but those of many employers.

Inflexibility is in my experience more often associated with a person than with their age. I've seen 30 year old devs that were absolutely incapable of changing over to new tech as it became available and I've seen 55+ people dig in with gusto. It's a mentality thing. Sure, mentality can change over time, maybe someone that's older is going to give something new a little while longer before hopping on the bandwagon or maybe they've already seen something similar fail in the past which is why they might be reluctant.

But flexibility is a hard-to-measure parameter to begin with and you need to know the people and their reasons before you can make call about it rather than simply their age.

Once you're old enough, you'll realise that if your plans change weekly you're in serious trouble.

Reply on news.ycombinator.com