rockemsockem

Honestly I think thinking has been a hobby for at least the last 15 years. It's plenty possible to get by in this life and be okay, but not great, without having to think very often. This is one of those bubble-in-a-bubble takes IMO.

EDIT: Thinking more about this...maybe it has always been a hobby?

For sure there are great engineers that are from Europe, I've worked with a bunch in the US, but it's a numbers game, and there's no competition there. Partly because so many of those great European engineers come here.

Lots of things have lights on them though. I'm thinking every status light on every piece of hardware.

Edit: also, I'm not exactly filled with knowledge on new lamp design/construction, but I have seen startups/kickstarters that make new lamps that seem like redesigns from the ground up.

Yeah, that's what I figured you meant. It absolutely is usually the database, guess you're also saying it's not the server-side either lol

By "web-side" you mean the client side I assume?

I think architecture is overemphasized a lot.

I am quite plainly talking about writing code that runs efficiently to support a wide-variety of tasks. To do that, one needs to write code that runs fast on your targeted platforms and is extensible/easy-to-modify (not necessarily the same thing to be clear).

We may have different definitions of "architecture" though, I tend to think of "architecture" at the system level, i.e. "this service handles these responsibilities, this other one handles these, they communicate with this interface/contract, etc". I can see how you could take the term "architecture" down to a lower level where you talk about classes/files passing information between each other too. I think to do that sort of lower-level architecture well though you basically need to write code in your design, even if it's just pseudocode.

I did not mean to imply that consensus, stakeholder buy-in, and strategic direction are easy, or even that they are easier than writing good code. My point is just that the code part is not easy either. I think the article's point that "if good code was easy, we'd have amazing software everywhere instead of crappy software everywhere" is a very good one. The average code that gets written is horrendous, interviewing people who are presently employed and struggle to write a for-loop makes this really apparent.

One thing I wonder about is how applicable your statement about web apps is to something like lamps or lighting generally. How many electrical engineers have re-designed a circuit that turns on/off a light? Are EEs who wind up doing mundane engineering like this still engineers?

Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely stood the test of time. Then ripgrep comes along, it has the same contract as grep (with I think a few inconsistencies that were intentionally tweaked for modern use-cases...and also I'm sure a few edge-cases from its design), but is significantly faster. The fundamental contract with the user stayed the same, I'm sure some of the design changed, but fundamentally the only difference is the underlying code. And that makes such a big difference that I *always* use ripgrep over grep now as do many others.

I think civil engineering is the main field in the US that relies on certifications/tests for FE/PE, there's probably more I'm unaware of though.

As I pointed out above though, aerospace engineers (working on rockets/space applications anyway, IDK about planes) and electrical engineers don't need those tests. Requiring it for CEs seems like a historical artifact more than anything.

European countries, historically known for their dominance in the field of software.

This is such a tired take.

Aerospace engineers who build rockets do not have some certification body allowing them to be called engineers. Same with most electrical engineers working on almost everything.

If you think a government deciding who is an engineer is a *good* thing then maybe you should ask yourself why the United States which doesn't require this for the two non-software engineering disciplines has the best engineers in the world.

I agree that all those pieces are important, for sure. But it can all be undercut by a few for-loops that don't consider string re-allocations. That covers the "don't understand good code in the slightest, make big mistakes" side of things, but the other side is being able to think about the algorithm that is being run in your system (sometimes across multiple layers of code) and writing code that eeks out the highest performance from the system you're on in the programming language you're using. Also, to be clear, "the algorithm" here doesn't have to be super complicated or theoretical it can be as straightforward as assembling some data structure in response to a user's query across a few different sources. That process requires being able to write good code.

IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.

If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.

All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.

Starlink satellites can provide anyone with Internet.