Yeah, I feel the same, I think I am better in a lot of regards than I was. I wonder if 20 year old me, meeting 45 year old me, would agree.

But it's definitely something I was afraid of. Representation matters in this kind of stuff too. If all the 40 year olds you know talk and think slow then you tend to draw the conclusion that getting old slows you down. Or at least, I dud.

I was probably capable of producing more code/day when I was 20 than now, but that's because I was willing and able to work 60-80 hours/week if I really cared about something.

I'm doing some pretty kick-ass stuff at age 50.

From my experience, the thing with being young and brilliant was I usually only needed the brilliance to wrestle with the impossible-to-maintain spaghetti code I created. Once I eliminated the spaghetti code, it became all about organization and trying to see around corners based on past experience.

I kinda feel like any code that takes a while to grasp is probably doing it wrong.

However concepts like asynchronous programming, closures, idempotency, etc. - are worth learning imo and do take time. Maybe when I was younger they would have taken less time. But we're talking an extra day or two of working with them maybe? Not a big deal imo since you don't need to learn entire new concepts that often.

My timed white-boarding sucks now though.

Complicated recursive stuff always seemed to tax my brain, so I might suck at that now too.

lmao

Lol that’s painfully real

Yea that isnt what happened at all

One important thing to always remember is that success breeds success and failure breeds failure.

Being in an environment such as yours with employees leaving for huge salaries and prestigious jobs at major companies while from all accounts your company seems to have zero vision and leadership at a stage where it is very weighted toward R&D vs actual revenue streams, is exceptionally demotivating.

I mean you could write an episode or Silicon Valley with the founders losing control and bringing in a ferry boat captain to crack the whip.

The reality is obv your skills and abilities are being massively devalued, not because they dont see you as capable and strong, but because simply they are bad leaders with little to spend and probably also avoid risk in classic erroneous ways.

The last company I worked at had a big story and some interesting superlatives, but coming from the business side I knew the fact the founders got the boot, they raised a few rounds (9 figures), and revenue was flat for years that all the problems would never get fixed because they had limited funds and given the above couldnt bring in top talent.

Unless you stand to gain an exponential and exorbitant amount of money from this company, there is probably a better place to be putting your effort into. The market is absolutely red hot right now and if you arent in a situation to take advantage of it you may be missing out on tons of earning potential that will seriously compound and make a huge difference on your life.

The first company I worked had 1 project manager. He attended a few scrums daily and was generally responsible for coordinating across projects and teams. This was a ~200 person org so there were not that many concurrent projects going on. Then we had traditional PMs who owned some part of the product features. But team managers (eng managers) did the hands on project planning, helping with breaking down tasks etc. A project manager should never be handing out tasks or giving estimates.

Second company is big bay area company. No project managers. The work is spread across PMs, eng managers, and tech leads. Some projects have very little hands on from managers so the tech leads will often take the project manager role and make sure everyone continues to make progress, is unblocked.

It's not an issue at large tech companies. You are measured based on output and impact not age. Just hit a terminal level that you're happy with pay and WLB and can retire at that level. Lot of people do this in Microsoft at Level 64 or level 66 (equivalent to senior and principal at other places).

I think programmers' fear of becoming too old is overstated. As long as you keep up with technology, keep coding skills sharp, and take on more technical leadership, there will be plenty of roles. Especially in big companies there are opportunities to become the deep expert in huge areas of the stack. Basically the architect level, where you are consulted on all major changes, and give guidance on how to execute. I think ceiling is actually higher going deep as an IC than getting stuck at some middle management level. Obviously these roles are hard to come by and it's probably easier to make more money going straight management/eng director route. But that is less fun and interesting than pure technical for many people.

Ageism is a thing imo.

A lot of technology stacks exist. FWIW technologies become obsolete, new tecnologies emerge. Some gain traction, some do not. One example is desktop systems and devices like graphics cards, disk controllers, etc. At one time writing Windows device drivers for devices was a skill in demand. Today not so much. Mobile devices ftw. Learning about emerging technological areas that will gain traction is a very challenging endeavor.

True.

Serious question: if a product person came up with requirements for a form, that shows how to display validation errors for various fields, would you think that the product person would also need to add a requirement that the form cannot be submitted unless there are no validation errors? Or would you think that's assumed?

Lol I would think it's assumed. I know sometimes stuff like that gets specified and sometimes it doesn't, but like come on use your brain and experience code monkeys

Seems like a simple thing to verify with the product person, then get it T-shirt sized and prioritized into the backlog and perhaps negotiate to get into the current sprint, maybe add it as a stretch goal or something, you know, keep it light and fun...

lol

Scrum ftw

I am with Suzzer. I have learned if it is not explicitly outlined you better not do it.

Based on personal experience, I wouldn't assume. I work with a system where a (small) percentage of clients want to be notified of validation errors, but still want a form to submit. Because "business reasons".

Having spent weeks looking for ****ty data that was blowing up our data model I no longer care that the client wants to enter ****ty data into the system. It's easier to validate it going in than all the places it comes out.

The flip side is that it’s sometimes (definitely not always) better to piss off your data guy then a customer.

Over zealous validation is super annoying and it comes up in all sorts of places. This is especially true for non-Americans, people that have lived in different countries, or really anytime that somebody is in some situation that happens 0.001% of the time (which still happens a lot).

Latest one I saw is a friend who is building a home in a new subdivision but because the road isn’t officially opened yet their address is rejected by a bunch of different sites that validate address against some official location data.

LOL

This actually came from frustration at a dev on our team - who implemented the validation logic, but didn't block the form from being submitted.

And of course since she didn't think about it in her design of the validation display, now it's a big task.

When you would EVER have a form that outlines a field with red box, tells you email address is required, but then just lets you submit the form anyway?

Maybe so. But our form is user data. It's been made clear that if the user wants to add a new address (say business address) - address, city, state and zip are required. There is no universe where we want to let the user still submit the form with one of those blank.

Personally as a dev I tend to think of these things, as do the other devs on our team except for one.

We're a small team with basically no process, and we have a designer and requirements person who are doing their best but are nowhere near the level of calling out every single little detail like that. Literally their first pass at this big form had no requirements whatsoever - just a visual layout - for a massive form with 3 tabs and one big submit button (which I hate - how am I supposed to jump around to multiple unshown tabs if the server comes back with errors?).

Not only that it has stuff like a user can have 2 addresses, 4 phone numbers and 2 emails. But we don't just show 8 blank fields. No that would be way too simple. We add and remove things. But of course the design came with just an add and remove button. No thought about how we should display stuff like phone type (say the user has already picked a home phone and business cel - so the type select dropdown should now only show home cel and business phone - etc. many many more hidden requirements like this).

I had to go in and document all the hidden requirements - most of which I just made up on the spot based on way more experience with web-app forms than I wish I had. Which of course then I get pushback on some - and I'm like - then specify that **** in your design and requirements please. I just had to figure all this **** out for you - but now we have to argue about one of the 20 things I just worked through?

So the upshot is I need devs to think about the big picture and not just program by rote. I get that if you work in a shop where every little thing is called out, then you can just assume if something isn't called out, there must be a reason for it. But we're clearly nowhere near that kind of detail. I find it hard to believe it never once occurred to her that the user should still be able to submit the form. I kind of feel like she's fighting a passive-aggressive battle against our fuzzy requirements.

I would love for our designer and requirements person to be more on the ball, but I'm much more concerned with impressing our business partners with a solid app that doesn't have dumb UI/UX issues.

Anyway she's trying and is getting there I think. So I'm not bashing her. I was just curious and I guess there's not a consensus of opinion on this.

I LOVE LOVE LOVE how Word spellcheck just randomly stops working out of the blue, and then makes you go on an internet hunt to find out that there's some magic combination of Tools:Language and unchecking the "Don't spell check as you type" box.

Which also refuses to work and just goes back to that weird partially checked thing until you figure out to uncheck "Detect language automatically".

I mean literally while I was typing a 5 page document in English, apparently about page 3 it decided to just switch languages and stop spell-checking. Awesome use case! Definitely something people need and want.

The new place I work allows you to edit a multiple page list but if you don't submit at the bottom of each page that page's edits aren't submitted. Fortunately, we don't track these things so we don't know how much money this tech debt is actually costing us...

We do that! Kind of. We have backend validation. so the red box doesnt show up until you submit. so if you submit bad data twice, the second time will surely have a red box on it.

There have been many seemingly absurd things that I thought should be added or changed. I have proly been wrong as often as right.

but even worse, even if I am correct, due to Scrum, everyone throws a fit if there is work done that is not in a card, esp QA. and we surely cant be changing cards at a whim and in the middle of a sprint. they need to go thru backlog grooming and business approval and sprint planning.

I feel like there must be a cleaner way to do this. The scenario is for some users with a lot of giving history, loading the giving history with their profile (which gets loaded at login) was causing a big slow down to their login. So I am now lazy-loading the giving history in the background right after the user logs in.

The method below is a service called any time anything in the app wants the giving history. So the flow is 1) it's called right after the user logs in and 2) it's called again if the user goes to the giving history page.

If their giving history is still loading from step 1 (which it can take up to 15 seconds for some users - we need to do server-side pagination eventually - bleh), they wind up in the else block and basically the function waits until localStorage.givingHistory is ready. So basically the second call is just waiting for the first call to finish.

Can anyone come up with a cleaner, more clever way? I always feel a little queasy about something like isLoading as a global var, but in this case I can't see where it really hurts anything.

I guess I could split it into two services, one that loads and one that just waits. But it would look pretty similar. And I like this because the app doesn't have to care which is called first.