nsfyn55

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.

easy peasy.

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.

He's not wrong. He should use actual logic rather than just trying.

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.

It's actually owned by the government, Fannie Mae.

Oh my bad. So riddle me this. Does the government secure mortages it owns?

The borrower is sort of using logic, but because of his extreme level of entitlement he fails to understand his premises are flawed.

Low rates are a function of your total risk not your perceived status as a responsible borrower.

The lender is using logic(the refi equation was almost certainly devised and reviewed by a qualified actuary)

Wealthy Borrower: "Why can't I refi lower?"

Lender: "No, because your loan isn't secured by the government"

Wealthy Borrower: "I am just using logic here, you're telling me a riskier borrower with lower credit than me can refi?"

Lender: "If their loan is secured by the government, yes"

Wealthy Borrower: "I don't understand"

Lender: "Well at least we agree on something"

Are you really using logic? Seems like a dubious claim to me. Capitalism is a harsh mistress Mr.1%. Don't like it move to Denmark.

This article is pretty confused.

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.

Unix Pipes - BWK pointed out in his memoir how a small piping implementation done in a single day changed Unix(and computing) forever.

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"

Is it really the trendiness?

Here is what would be going through my mind...

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.

@@

A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer.

What does this mean for crypto players that exchanged a lot of crypto, realized gains, then lost their wallet?

Are they still on the hook for taxes on the gains even though they can't access the wallet anymore?

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.

You asked how it would help and I explained exactly how it would help. I directly addressed your point.

Your content free, one sentence response not withstanding. Is there something specific you'd like clarification about?

Easy. Civil law operates on a concept called "preponderance". It's not absolute in nature it's a measure of likliehood as measured by non subject matter experts(a judge and some randos). Imagine a person has fallen on your property and injured themselves. If you are known in the neighborhood as a person that takes care of your sidewalk(shovels, patches broken concrete, etc.) and can produce evidence(character witnesses, testimonials, visuals) to that effect your case is strengthened.

No one ever got directly hacked because their password was too strong, but lots of people have had passwords guessed by brute force.

So put the two together. Its beneficial to have strong passwords because they can be presented as evidence of due diligence and there is no security risk to enforcing them. There may be some business risk(people fleeing because they don't like your password policy) but someone needs to quantify that its a problem for it to be considered in the calculus.

They do matter but not for the reason you'd first think. It's about liability. Imagine a bank testifying in a hearing about a recent data breach. They are going to want to give the perception that they have done everything within reason to protect their user's data. Password restrictions are a cheap feather in one's due diligence cap.

I saw him run over forty several times, and it was not unusual for him to put a string together of twenty or thirty

They are almost certainly talking about 14:1 continuous which was far and away the most popular pocket billiards game in the 1930s,40s, and 50s.

40 is pretty good but great players regularly run over 100 and John Schmidt just ran 600+

"Tech Debt" and "Code Quality" are myths. I know that is an unpopular perspective, but allow me to explain. To start with, for me everything is just a problem described in terms of its properties.

What are some examples of problems I have encountered that were worth solving?

1. We have a server rendered site and an API. Changes to the server rendered site require matching changes in the API code effectively duplicating our efforts. If we re-implement the site as a single page app consuming the API we can kill two birds with one stone.

2. The lacking test coverage of a critical section of code matched against the frequency of changes to that code results in a frequent regressions and delays.

3. Unifying two divergent implementations will allow us realize a shared, multi-tenant deployment model for our partners. The load characteristics will give us the same point of presence for half the hardware.

Why are these worth solving? Because they have objective rationales. The third embodies a strategic direction with real bottom line consequences. The case can be made "If you want this outcome here are the steps" Then the only question becomes "Do we want this outcome?"

Many times "tech debt" and "code quality" are tossed around as easy justifications. They lack the intellectual rigor or organizational context to make a compelling case that its worth the opportunity cost. The person using those terms generally has strong feelings that its the right path, but can't really articulate why. In many cases there is no "why" and its more a of a "just because"

In my experience "Tech Debt" projects that are actually undertaken or not called "Tech Debt" they are called "Lets do this because its important to the business and here is why" projects.

When are you people going to understand that your first amendment right doesn't protect your right to post on the internet. It just stops the government from making laws that restrict your speech freedoms. Reddit and Youtube can sensor you all day and its perfectly constitutional

I would say both, but if I had to choose one I'd choose shipping. Anyone who has ever code spelunked through a multi-year code base notices something. Most code is written and never touched again, good or bad. This means most investments to ensure maintainability yield no return. I think a better approach is to exercise good judgement. Critical, high churn/high risk code is easily identifiable and should be given proper attention. Code that is not critical path, trivial in complexity, or unlikely to change can survive with more lax standards.

OP says 10X programmer is a myth. Then describes the exact characteristics that make some programmers 10 times more productive than others. Maybe not so much a myth.

I'm gonna bet comment author says they use Xcode for Swift/Objc and Vim/Tmux for everything else. I just came off a small Swift project. Apple makes it difficult to code for their products outside of XCode.

Why does clicking blog take me to a "Hello World" application?

Does anyone have any practical advice on people understand the importance of structure code, and to limit the _personal factor_?

I'd take a step back. When people "don' t understand the importance of ...." the issue is almost always a breakdown of bi-directional communication. I like to start by assuming the person offering resistance has a valid point. Start by telling them they are right. If their approach is causing a problem then describe the problem in objective terms. Present your analysis to the resistance leader and ask for their help in solving it. When you do this the person offering resistance can often become your biggest advocate.

Recently I have become a convert of the retrospective with a focus on incremental improvements. Start with the process you have and commit to making it better with 1-3 concrete action items per cycle. It can be surprising where you land.

when it was time to review code, what we really looked out for were obvious bugs, problems with the design or architecture and where code should be located. Variable naming was inconsistent but no one really bothered to enforce them. I don’t blame them, making code review a nit-picky task really puts a damper on the mood.

As a veteran of a dozen different code review approaches I've identified a few properties of those that succeed and those that fail.

If you want your code review process to fail its easy just...

1. Make it about you and your preferences. Does this code adhere to my particular aesthetic preferences? Are the variables named the way I would name them? Do I consider this code readable? How can I force others to adopt my perspective? Remember the purpose of code reviews it to keep iron-fisted control of the code base such that it never becomes that dreaded "big ball of mud"

2. Demand that the team adhere to a set of rigid rules regardless of how practical their application is.

3. Most important focus mainly on the subjective qualities of the code(format, spacing, naming, etc.) Allow non-critical path items to hold up delivery and use those items to critique others based on an arbitrary measuring stick.

If you want your code review process to succeed. Its a little harder....

1. Be problem focused. What has bitten you in the past? Are you sure you understand the cause? Acknowledge that there is no "right way" and that you will build the perfect code review model through trial and error.

2. Start with the bare minimum and build on it with a regular retrospective process. Allow your team(s) to take ownership of the code review process both as an expression of what they want to accomplish and as a way to improve their daily lives.

3. Accept that you might have been the one doing it wrong all this time.

4. Focus on the objective qualities in the code. Is this the best approach to solving this problem? Does it work? Are there any obvious bugs? Based on our collective experience will this code cause problems later?

5. If you feel like you are nit picking then you are nit picking. Don't nit pick.

Code reviews can either be a tool to write better code or a form of weaponized OCD. Don't be the latter OP, you're better than that.