> been a professional engineer for 6 years

Man, the software world is just weird.

In the military 6 years is definitely considered senior and I’m sure that’s also the case in a lot of other fields.

It seems like (at least outside of the military) the duration to being senior and the importance of things not going wrong are correlated.

Additionally, "seniority" is relative and can vary between different technologies: for example, I have been working as a software engineer for 25+ years, and while I have worked with Java before I am no better at it than someone who just graduated. Similarly, even though I spent nearly a decade as a frontend dev, the last time I did that professionally was in mid-aughts, and I have zero experience with React, TypeScript and other modern staples of that area.

I'm not in the US though and also work as a contractor so it's hard to use titles like these in my daily work.

[1]: https://about.gitlab.com/handbook/total-rewards/compensation...

But in software (and perhaps all knowledge work) many many times its the lowest ladder employees who are closest to the actual problem space. They are the ones dealing with the hacked up code base from 8 years ago, the indecipherable comments, the untested code that is critical to the business.

The job of the more senior people is not to command and control those employees, but to empower them. Bringing breadth of experience, or in depth expertise that is not specific to the problem at hand to help them make a decision.

Sorry, rant over.

That’s why one of the most important differences between a more senior engineer and a more junior one is the ability to mentor.

Title inflation dictates that there is and inevitably will be.

If you’re senior after six years, and you’re staff after 12 then eventually people will be staff after 7 years and there will be a new title above that which takes 12 years to get (principle?).

I haven’t seen a junior in 10 years, I haven’t seen an intern in longer. People seem to come out of school into “mid” level roles - which means the mid levels are actually entry levels and the titles shift down.

Only in industries where software development is not a primary business; beyond Senior there's titles like Lead, Staff, Principal, Distinguished and Fellow SWE, or branching off, things like architect.

Anyway, senior engineer is less about what languages do you know and more about making informed technology decisions, maintaining quality, managing and training less experienced people, etc. It's also - IMO - not down to years of experience, because you can have 25 years of experience but be stuck at a certain level or stuck in a certain technology.

(And how lucky they are at getting promoted withing that company)

Staff, senior staff, principle, distinguished, architect, etc?

Don't see how that's possible. I wouldn't even think 50% of what makes anyone a good Java developer is due to anything Java-specific. And you'll undoubtedly pick up Java-specific knowledge faster than the graduate is likely to.

Also the quote is 'professional', so although it's probably not the case, it doesn't preclude spending your 6 years in 'graduate school' beforehand anyway.

You don’t have to do a postdoc.

I think you confused the JS ecosystem with the C# one.

What do you mean?

Although I don't see why you're bashing C#. Despite the .NET Framework > .NET Core > .NET transitions, it's not really that different. There's a ton of new functionality and ways to do things, but for the most part the old ways still work too.

I could even see that going faster than 5 years, especially in a startup. For example, say one of your early hires is fresh out of school, but really curious and learning fast, already did some open source, learns from mentoring/osmosis, takes easily to a team sensibility, and has to tackle a lot of things like is the norm in a startup. Within a couple years, as the startup is starting to think about titles more, they might be a battle-scarred veteran with firsthand experience and maturity beyond their years. (Or, even if not everything is yet the complete senior package -- such as maybe they've only worked on one system and team, and could've overlearned from limited data points -- you want to acknowledge the value of their contributions, as well as their institutional memory and cultural role. So maybe help them level up any aspect they haven't yet had a chance to.)

(BTW, I avoid the term "professional engineer" when talking about software, because I've heard it have special meaning in the more regulated, traditional engineering disciplines.)

It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends.

There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems and were never around to see your bad decisions bear bad fruit.

However, the opposite does not hold. It doesn't matter how intelligent you are, you can't short circuit repeated experience and the mix of breadth and depth required. People want to. I wanted to. But I didn't: all I became was an overbearing mid who had the rhetoric (and the OSS contributions!) to convince others I knew what I was doing. There is absolutely no comparison between myself in 2017 and myself in 2022, but we both have a job title of "Senior Engineer".

In fact, I think that in the long term the trend is for the senior bar to get _higher_. This is pushed by two things: firstly, that the technical domain gets harder, software becomes more abstract, our expectation of engineers increases particularly in "left shifted" environments where every IC must do everything from frontend to microservices to infra to security to testing.

The second force is demographic: as IC salaries have increased, there has been less pressure for senior engineers to exit in favour of the management track. That means more experienced engineers on average. Industry needs a way to describe these practitioners, beyond "very senior", and overall the range of skills of ICs will widen. Under those conditions the definition of senior engineer gets more exclusive, not less.

Are there those who are masters of their craft who call themselves a senior, of course.

I'm trying to reconcile meaningful titles with current industry norms.

I'm open to other schemes, but, FWIW, this is my current rough idea:

* First is some kind of new college grad. Some of whom would object to Junior in their title, and I think Technician sends the wrong message about near-term goals, so I'd just call it plain Software Engineer.

* After maybe at 1 or 2 years, they've been through some projects, and they know a lot of the mechanics (big contrast to a new-grad who learns as they unlearn what they got from bloggers). You want to acknowledge that, so maybe it's Software Engineer II.

* At some point, maybe it's 5 great years in, they've seen a lot of stuff, and gotten wisdom and insight, and Senior sounds about right and conventional. This could be a plateau title that someone has for a decade, even as their TC increases quite a bit.

* Staff and Principal engineer roles transcend project teams (more than Seniors do). Large companies will each have their own definitions, and there might also be unwritten meaning. (At my first hardcore software engineering employer, there was no Staff, and only a tiny percentage ever made Principal. By the time I made Senior, the VP asked me where I saw myself in 5 years, and I said Principal... He gently set expectations that that's pretty ambitious, only a few people ever do it, and 5 years would be very fast. Correct on all points, and now I think I have a better idea of how much more the Principals knew that I didn't even know were things to be learned.)

There's definitely inflection points at years of experience:

0: Good enough to be hired

1-3: Solid team contributor

3-5: Best IC on a team

5-8: Lead a project/team

8+: Lead multiple projects

Then from there it's increasing complexity of teachnical problems and project size.

If you're insisting that senior applies only to the last level what do you call all those steps between 0 and 8.

But what if you were outside the industry and heard that term? A senior judge typically has decades under their belt. A senior chief petty officer is the second highest non-commissioned rank in the navy implying a whole career behind them. They might infer it only takes three years of experience to reach the near top of the software craft.

It’s just as stupid but there is a different reason for it.

A senior judge is also quite literally a semi-retirement role. You take on reduced workload.

> But what if you were outside the industry and heard that term?

"Senior Associates" in the legal profession are junior/mid roles, similarly, senior account managers etc. aren't particularly senior in most places. In white collar roles, a "senior" is really just a distinction of independence and reliability.

I do agree that certain habits or experience from working for additional years might be missing, but as the first engineer of a codebase, IMO, there will always be something to learn from them. Which makes the article credible enough to warrant a read.

IMO "senior" is a function of behavior not time. At FAANG, levels are formally defined by traits. For example, a senior engineer can plan and lead 6-12 month long projects, delegating some parts of the implementation to others where appropriate. I personally was fulfilling this definition at 25 and I know several dozen others in similar situations.

PS: Viewing with JS on -- yes, totally unnecessary eye-candy fluff in that animation.

    @keyframes fdsseq { 
    100% { opacity: 1; }
    }

    #fds p {
    animation: fdsseq .5s forwards;
    }
    #fds p:nth-child(1) {
    animation-delay: .5s;
    }
    #fds p:nth-child(2) {
    animation-delay: 1s;
    }
    #fds p:nth-child(3) {
    animation-delay: 1.5s;
    }

Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete.

I don't think I would enjoy working on this codebase.

Sometimes however, it is really difficult to come up with a shorter name. I think it is definitely a skill, that takes practice and never is really perfected.

I've found this to be a much better rule of thumb than "always use long variable names" or "always use short variable names".

This concept from CC was at the back of my mind, but couldn't articulate it, or even remember where I'd first read about it, but it's been something I've worked at adopting and growing over the years. 6 line loops - x/i/j/k/etc are all valid and usable. In some ways, it's actually more helpful to me, because the longer names indicate something concrete/real, and the single letter names indicate local/throwaway values.

For C and JavaScript I use single letter indexes ijkl or "current".

I think it's a personal preference. I don't think there is a wrong way or a right way. Your team needs to agree though. I would be annoyed if I implemented a deep feature and the PR was blocked due to something as inane and useless as this.

I worked on parallelizing nested loops across OS threads and load balancing between outer loops for different progressions through the loop. I also wrote some code to reverse the loop direction to avoid a cache miss when the indexes go back to 0.

https://github.com/samsquire/multiversion-concurrency-contro...

`i` and `j` are usually indicative an index for something, and indicating what you're indexing makes the code clearer to read and easier to maintain. `idxUsers`, `idxPosts`, for example. `x` and `y` are a bit trickier because they're very frequently the canonical positional co-ordinates, and renaming them can actually make it _harder_ to read, so (like all things in naming) is a real judgment call, but frequently can be replaced with `col` and `row`, which, to me reads _much_ clearer, especially when using row-major access pattern: `array[row][col]`.

My standard solution for this is to name the loop counter for the things being counted. So your example would be:

    for (horse=0;horse<n_horses;horse++) {
    }

    for (horse in horses) {
    }

One anecdote I remember from the book, is how for a while Excel allowed for dual colored cells based on a parsing error due to trying to be too clever.

Longer variable names are certainly a facet of Clean Code. It's in chapter 2, and Chapter 1 is an introduction.

That said, I strongly suggest Arlo Belshee's series https://www.digdeeproots.com/articles/naming-as-a-process/ - this gets to the heart of how to have both descriptive and not-sentence-long.

https://journal.stuffwithstuff.com/2016/06/16/long-names-are...

Now I read this blog and my head just exploded in the functional part.

It's beautiful.

What good introductions to functional can you people point me to?

Also, good code is like prose. You write to other to read, and you need to guide their minds.

Of course you can write in dense, truncated and clever ways, but your audience will be small (even yourself won't like your own prose 6 months from now).

Good software is delightful to read.

Anyway I would recommend learning Haskell. I like languages that allow different styles (like js does to a certain extent). But I think it's better to learn a modtly pure OO language like java and a pure FP language like Haskell to be able to make the right decisions in a language that supports both like JS.

I would link to the section "Functional, declarative programming" but there are no anchors. The table of contents (which the author calls a "minimap") is not clickable either.

When people hear "functional programming" many of them will immediately point you to Haskell (and totally forget to mention The Haskell Pyramid [1]). I'd advise you to stay away from it until you _want_ to go deeper down the rabbit hole.

Play with Elm and Erlang ("Programming Erlang" [2] and "Erlang Programming" [3] books are great) to un-learn imperative patterns, tinker with OCaml to learn a new way to modularize code.

[1] https://patrickmn.com/software/the-haskell-pyramid/

[2] https://www.amazon.com/dp/193778553X

[3] https://www.amazon.com/dp/0596518188

There is also this new thing I found that seems to really lean into the core of what being functional means here: https://github.com/jorgebucaran/hyperapp

After a while, you see that basically all systems can be modeled as event-driven, functional systems. It’s a flexible model, and fits beautiful into web dev where the semantics are very clear: the system is the web app and events are clicks, keyboard events, asynchronous calls...

To give a trivial example to illustrate the conceptual difference: a declarative program could say something like "the output is the solution to f(x) = 0", defining f explicitly and leaving it to the compiler/interpreter to supply the algorithm for figuring out an x that satisfies it. Note that, as long as x is unique, "try all legal values of x" works, so a viable fallback algorithm always exists; it's just inefficient. Whereas with FP you actually have to supply an explicit function to (hopefully efficiently) compute the output, i.e. you basically have to write f^-1 yourself, which typically results in a very different program - sometimes harder to read, sometimes easier.

Now, of course, you could do "FP" by writing f instead of f^-1 and then enumerating all possible inputs as with DP, just as you could write a DP to compute functions explicitly at every step, and you could write imperative programs for all these. But those would be unnatural, and would generally defeat the advantages of the paradigms.

I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design.

Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver).

The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges.

Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...

Undelivered pretty code doesn't deliver any business value.

Same applies to 100% code coverage that isn't running on customers computers.

The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.

So you better not tie your self worth to the quality of the things you produce.

You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.

You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.

There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.

Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.

It is a balance that needs to be learnt, and a trait of seniority.

Make it work and make it as straightforward as possible.

This philosophy less relevant in larger companies with more engineers also.

I get your point, I just question the specific example.

See also: https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).

I think quality in terms of correctness is always the target, and performance usually has a target SLA.

So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.

> Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:

The conversations aren't about code quality -- they're about a finer point of it and in concrete terms rather than in beginner terms.

I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.

Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.

Nobody can quantify 'good-enough code' but everyone can quantify meeting a deadline.

How much engineering is anyone really doing anyhow - or are we calling using React to build yet another set of forms users fill out with some error handling engineering nowadays? :)

In the company I used to work at, code quality was a huge deal. I think, destructively so.

Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly.

As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to see, when revisiting, six months later.

On another note, this industry considers six years to be "senior." I find that interesting.

[0] https://github.com/ChrisMarshallNY#browse-away

I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made.

This was one of the biggest pain point for me, moving from my own personal projects to working with other people.

Managers often neglect to take team overhead seriously.

This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate.

However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.

I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.

The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need.

So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part.

I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.

Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.)

Of course, that may be different perceptions of “good”.

I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures.

So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.

Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc

His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should.

Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.

You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.

A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer.

This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example).

At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'.

And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.

Reading through, it looks like I have some rough edges of my website to clean up as well...

Good writing is, to me, the foundation of a good engineer. I know excellent engineers who are not great verbal communicators, but every excellent engineer I know writes like you do. I think it is the result of a structured thought process, that flows naturally into a structured clear text.

I did mentor a couple of interns that were juniors in college, though, and they were awesome. It might just be me that takes 10 years to get it.

[0]: https://en.m.wikipedia.org/wiki/John_Carmack

Or to a mechanic that fixed many things in many different cars over 10 years ?

Thats the difference between hoppers and “veteran corpo ppl”.

2. Do you want a whole car designed by someone who designed the hubcaps of a Ford Model, and the driver's side door handle for an Audi, and a dash switch for Toyota, and on through 10 other random parts? Or do you want someone who has been part of a team that designed a whole car before, from start to finish?

Average project in IT is built in 2 years. In 8 years you could have built 4-6 different projects.

The dude that stayed in first project to maintain it, probably did not learn anything more.

Thats at least my experience. Old Java devs that stopped learning after java 8.

14 year olds have competed in the olympics, I would never claim that should be the bar for considering health for 14 year olds.

> Yeah its pretty scary, 6 years mean you've either only understood on one or two big systems, or you've job hopped more projects and never understood them in depth.

Which is blatantly false. I only need to provide one counterexample, and John carmack blows this assumption out of the water. I wouldn't expect the average developer to be anywhere near that level.

But if the top percentile is shipping over 20 commercial products and literally changing the industry with a technical innovation in only 5 years, then I would wager it's very attainable for an average dev to reach a "senior" level of experience in 5 years.

And that's the point, comparing exceptional people to the general population isn't valid or relevant here.

Also, these people are typically on teams as juniors who are learning.

Consider that you immediately reached for someone who is over 50 as an example of a developer having a large impact in the first 5 years of their career. That really does say everything.

An exception is a counterexample. For example, are all prime numbers odd? No.

Why not? Because 2 is prime and even. This is exceptional because 2 is only 1 out of a (theoretically) infinite number of prime numbers that are even. This doesn't mean I can now say, "All prime numbers are odd".

The OP gave a tautology that basically went, "If you've only had 6 years of experience, then you only worked on 1 or 2 big projects OR you've job hopped and have a low level of understanding". John Carmack is exceptional, but also a counterexample to this statement in both regards. He was also the lead programmer at ID when he made Doom, not a junior.

Besides this point, what does him being over 50 have to do with this? He was 19 when he started working professionally if I remember correctly, which means he was 24 by the time he made several significant industry impacts.

Besides that point, here are some more counterexamples to the original claim. Mark Zuckerberg was 19 when he started Facebook. Alan Turing was 29 when he cracked the enigma. Djikstra invented Djikstra's algorithm when he was 26. Bill Gates founded Microsoft when he was 20 and released Windows when he was 30. I have plenty of personal examples as well, but it wouldn't do any good to mention them since they're not famous programmers.

you're insisting on 2-valued logic, language does not work that way.

---

Here's what you're doing.

"seat belts save lives, therefore you should wear them".

"aha! There was this ONE car wreck where they would have died if they were wearing their seatbelt. It's a counter-example and therefore invalidates your point!."

Said no reasonable person, ever. What it IS is an exception to the general rule. Because it turns out, reality isn't 2-valued.

Reality is not 2-valued. I don't understand why you're still arguing this point. Yes John Carmack was exceptional. And yes it's true that 6 years of experience does not automatically imply a junior level of experience. That's all I'm saying here.

It has nothing to do with years or getting depth in projects. Most projects are just data pipes. Hard projects are rare.

As pointed here, it is rare to work on interesting and trail blazing stuff - that's why it takes time, sometimes years, to gain the experience. There's a low probability of actually working on something meaningful, therefore you have to fight it with repeated attempts of finding the interesting stuff - and that takes time. Obviously, time is not the only thing needed to become a really experienced engineer, but - in almost all cases - its a prerequisite.

They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost.

> Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense.

I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

Have you never worked in a dynamically typed language?

what cost? aesthetics?

Personally I'm thinking more along the lines of

Succinct ->KEY

Verbose -> MAIL_SERVICE_API_KEY

But then somebody else needs to look at this code in the future, and they're scratching their head as to what these names represent. Or somebody didn't really put enough thought into what the variables are, or gave them a name that only half represents what they actually mean.

I basically threw away all care for how long a variable name is long ago and have never had a problem. I just name it with enough words it needs to describe what it represents and don't fuss with making it smaller. With a decent IDE you don't even have to remember the whole name for things half the time, only parts of it.

For my toy example I don't think it is because it's generally easy (in the languages I work in) to overload arithmetic operators on types that are basically constrained scalars so there's no explicit wrapping/unwrapping to do when you want to operate on them as if they were plain scalars.

Maybe you could give me an example of the kind of pathological situation you're alluding to?

Perhaps a qualifier would have avoided this whole issue, eg "my more senior teammate" or "my mentor".

Then again, this seems like a reader issue, not an author issue. The salient point was never that Chet had status X and therefore could teach skills Y, it just was that Chet taught skills Y.

There are days, weeks really, when I can't tell you what I've done. The business just chugs along. If I'm gone a day, though, my phone will ring by 10 a.m.

> Static typing is really a form of testing

No! Static typing is not a form of testing. Static typing or static analysis, is an approximation of you program behavior, because it is undecidable in general. Depending on the properties of the type system, you can guarantee that you program doesn't go wrong if it is well-typed, where the definition of 'go wrong' depends on the type system. On the contrary, testing can check the behavior of your program with respect to a set of inputs, and it doesn't guarantee anything outside that set of input. You are doing state partitioning by doing a static analysis over your code to determine what tests you may need, and test some of them.

For example, if I came across the example in code, I would begin to wonder why the `deltaX` variable exists at all if its only purpose is to be renamed `translateX` and spend some time tracing the code to see where the variable falls out of scope and to see if it's important. Then I might wonder whether it used for something else at some other point in time and trace the history of these lines (somewhat akin to nerd sniping).

Now I'm focusing on the variable as if it's important when really the important bit is the relationship of the current to the initial. The code is obscuring the fact that "delta" is `current - initial`. Look how many times the pattern is repeated! Perhaps we need an abstraction that can produce the delta for us. However, the data structure makes that a little bit tricky as scrollTop is held in an ad hoc manner, so maybe we should update the data structure so that we can eventually have an api like:

   type ScreenPoint = { x: number; y: number; scrollTop: number }

   type toDelta = (current: ScreenPoint, initial: ScreenPoint) => ScreenPoint

   // example implementation of toDelta using ramda for brevity
   const toDelta = R.mergeWith<ScreenPoint, ScreenPoint>(R.subtract)

   const delta = toDelta(current, initial)
   shadow.style.transform = `translate(${delta.x}px, ${delta.y + delta.scrollTop}px)`

please don't do that. Unless the article also uses Ramda (it doesn't) its not really appropriate for you to do so. If you want to use Ramda in your own, personal code, go ahead. But if you're posting a public example for other people to look at, including Ramda only makes sense if you're on a Ramda forum.

The whole point of this article is clarity in programming, you've reduced that with you decision to include some obscure package.

In this case, I felt that it was sufficiently close to pseudo code “merge these objects by subtracting identical keys left to right,” but I understand your objection to obscurity. I actually feel that the implementation in this example is fairly unimportant.

The author mentions doing Mindful Practice but later says to be Problem Oriented. The first one implies a background thread making judgments that is constantly running in the back of your mind. The second needs you to ignore everything but the problem at hand.

I’d go with the latter, esp if you’re new to the job. Let judgments accrue over time rather than go looking for them in the middle of a task at hand.

JS dev is a state of mind it seems.

I consider all of the lessons that he mentions to be things that junior engineers learn before becoming medior engineers.