My experiences with programmers that have more than 30 years on the job fall into 1 of 2 categories...
1. Constant complaining about the state of things(too much memory, too complicated, back in my day, blah, blah, blah). Why do I have to learn git?, containers?, on, and on, and on. VMs are just fine, what's wrong with java 1.4?, ... exhausting . These programmers probably sucked when they had 5 years of experience and continue to suck today. Crossed arms, learned helplessness level 99.
2. Crazy life long learners that have ridden one technology wave after another for decades on end. When something new comes out they are on it like flies on picnic food.
It's my greatest, most sincere hope that I have the energy, temperament to become the latter.
The "Architect" role varies from business to business. If you don't understand exactly how to be successful in your current role it sounds like you have some work to do. Find out who will make the determination about whether or not you are successful(spoilers it may not be your direct manager). After finding out who they are you need to find out what they consider success. Before you let that person go you have to setup a system for validating their expectations. "If we do this do you think we're headed in the correct direction? Can we meet on this regularly until you are convinced?"
Generally speaking one thing you can do in any technology leadership role is to understand your space. Take the space in which you are working and distill each major technology component into a one-pager. You should know from a high level how it works, what purpose it serves in the business, some basic cost/return metrics, what it interfaces with, what projects/initiatives are currently in flight etc. Basically a crib sheet.
Once you understand your space and what your organization considers success you are ready to get started. You need to build a plan to take the pieces of that space and manipulate them to make your handler's expectations a reality.
I don't think the author is a 1x programmer. He has learned the first secret of 10x programming. It's not about being a genius programmer. Its about being an efficiency expert and a problem solver. Soft skills play an outsized role here. I have seen immensely talented developers with hard skills for days manage to deliver nothing over long periods of time.
Learning that rules are guidelines not religious artifacts handed to us via burning bush is a big step. I can't tell you how many programmers I've seen hobble their own productivity by having overly aggressive code reviews, strict style guidelines, or requiring more testing than is necessary.
Being an outstanding software engineer is 99% knowing when to tenaciously stand your ground("storing state that way will not allow us to scale horizontally. It will save us a few hours now but in order to achieve our larger objectives will take 1000x the effort to unwind; we have to find another way") and when exerting control isn't helping("You can't put this simple, but incredibly important, time sensitive piece of software into production until it has been reviewed by our 6 committees, is re-written to use the companies globally enforced, yet questionably valuable style guideline, and has 113% code coverage")
>Capitalism doesn't mean an 'unregulated hellscape', capitalism requires a state to exist in order to defend the right to hold private property
Oh look everyone its another armchair economist who insists his conveniently specific definition of capitalism(You know the one that must be the case so his beliefs are not a self-inconsistent train wreck) is the absolute definition handed down to us by the word pope and sourced from a magic dictionary stored under his papal throne. The first time in the history of the internet.
According to my alternative word pope if every bit of ownership isn't private and it isn't devoid of regulation it can't be considered capitalism. See how easy it is to make up a definition then argue from it like its gospel.
Alternatively you could accept the much more reasonable circumstance that economies are messy things. Although some stress one economic principle more than another none can be purist in nature.
I'm not familiar with what changes occurred during the financial crisis. Fannie Mae and Freddie Mac always enjoyed an implicit guarantee that their balance sheets were secured by the federal government. It was a big inside joke forever.
Right just like there are no capitalist nations in the world. Because no nation is a completely unregulated hellscape governed by pirate kings. Spare me the semantics.
Articles like this are often written by someone that manages a trivial or non-critical path system. They have strong feelings about logging because they lack other things to have strong feelings about.
This person seems confused in general. They say "don't log, send it to sentry". Sentry is logging. Sentry is usually configured as a logging destination. It just does some preprocessing on those logs to aggregate and enrich them.
I don't know anyone that fishes through text logs over ssh anymore. We use simple automations to roll everything up for convenient access.
Furthermore he overlooks other use cases for logging. Including analytics, fixing concurrency/heisenbugs, and a myriad of other problems that logging addresses.
This might be the most short sighted article I have ever read. One of humanity's greatest achievements was the creation of the intermodel shipping container(https://en.wikipedia.org/wiki/Intermodal_container). We literally would not live in the world of convenience we have today without it.
But imagine what the curmudgeon of the day had to say about this. "Why do I need to use this specific container? This container has all these problems... and on and on"
> Why after investing 11 years in Mike did Microsoft decide to let Mike go?
People are tremendously expensive to a business. Losing 11 years of IP is a nightmare scenario. This would be a clear red flag for me as a hiring manager.
My second question would be...
> Does Mike's resume look like he's kept up on what's current? If not could that be why Microsoft let Mike go?
The only question I am asking when I hire someone is. Where can I put them on day one. If I can't see where a person fits in then I'm not going to hire them. The worst thing you can tell me in an interview is "I'm willing to learn". Great so is everyone else. What I want to hear is "This is the state of the market, this is what I know now, these are the things I should know, this is how I plan to know them" and "what do I need to know to meet your needs on day one"
>Mike has worked on systems that can handle multiple orders of magnitude more load, but his experience is, apparently, irrelevant.
No one really cares. I don't care if Mike was on the nasa team that sent men to the moon. Tremendous achievement, useless to me right now. I care about what he can do right now. Does Mike have the answer to the QPS problem right now? If he can why isn't he there right now pitching them the solution.
There is no earned comfort anymore. You don't stick with the company long enough to get the good parking spot. No one cares what you did yesterday they only care about what you can do today? If Mike is on board with these values and is keeping pace with the skill demands of the market then I don't think he'll have any problem finding a job at TrendCo or anywhere else. If Mike thinks he's owed something for the time he put in at Microsoft then I suspect he's in for a rough go.
And where does it talk about the plight of this poor, poor libertarian, law abiding man that lost his home because of an $8.41 oversight? When a story is legit it gets picked by multiple outlets. When it gets picked up by reason.com they tell you about the seizure but they conveniently omitthe part where he dug his heels in over this $8.41 payment and refused to settle his bill for 2 decades. Threw the 14 notices he received in the garbage. Missed 6 court appearances, spent a night in jail. threatened the district attorney. then finally the seized his property and sold it.
Not saying that system isn't problematic. I am saying this story and its source are trash.
Look at that sally, a false equivocation right out of the gate. I'll just change your text so that it represents what I actually said ....
>How exactly does taking steps that have previously been used in civil suits to demonstrate due diligence such enforcing password requirements going to demonstrate due diligence?
Well I'm glad you asked billy! The answer is tautology. Thanks for playing.
This argument is stupid. You want to talk about yak shaving, theoretical nonsense. FWIW I agree with you and think that password requirements are dumb, but you live in the real world. These are the legal realities of IT policy.
1. Constant complaining about the state of things(too much memory, too complicated, back in my day, blah, blah, blah). Why do I have to learn git?, containers?, on, and on, and on. VMs are just fine, what's wrong with java 1.4?, ... exhausting . These programmers probably sucked when they had 5 years of experience and continue to suck today. Crossed arms, learned helplessness level 99.
2. Crazy life long learners that have ridden one technology wave after another for decades on end. When something new comes out they are on it like flies on picnic food.
It's my greatest, most sincere hope that I have the energy, temperament to become the latter.