sadness2

Sounds too cheap

The thing is, most of these snippets are almost unreadable. That's Python, though.

Why hollow?

I still give it credence.

Learning anything is good for your brain. Lots of other things involve sequence and symbolism. Lots of other things involve fine motor skills. Why not learn introduce something else, like knitting?

This is a narrow view. The fortune 500 provides no insight into the level of interest each economy holds in the major companies of other nations. Spoiler: the US owns a fucktonne of the world's capital gains

I don't understand why they don't just improve working conditions. Why don't they improve compensation and make it more human for the humans involved? It's not going to make their business less scalable. It's just going to lift the cost curve up a few notches. Amazon can definitely handle that additional sunk cost, and the good (and actually deserved) PR they would get from that would be enormous. Not to mention it's the right thing to do

Superb. This analysis shows that you are not only able to process data, but that you will creatively find opportunities to make data useful, in ways which other folks in whichever company you end up in may not even think to ask for. If people with data science openings are not attempting to hire you from this thread, they're crazy.

Your team appears to lack diversity with regards to age, and your conclusion makes it sound like that was almost a goal. Older engineers can offer a lot of wisdom and save a lot of wasted effort

TLDR; people who use more data have to pay for more data

Interesting! Which part(s) of the US do not mean this literally? What does it mean in that context?

Worse is that these are cached by Google so any admin seeking to clean up this mess sure has their work cut out for them.

What is the difference between the genes identifies as "extra-species sourced" and those which are a nominal part of homo sapiens DNA? How do we know they don't originate from intra-species mutation, for example?

Experience has led me to conclude that code maintainability is a Team. Dedicated staff are needed to recommend cross-cutting solutions, roll them out company wide, perform refactors and clean up technical debt. Making it a "culture" is too hard. It means getting buy-in with regards to how crucial the function is for the sustainability of product development, but once it's a job description, it will actually happen.

Breaking this cycle of blocker-blocker-blockers is what makes me actually like Adblock Plus's "Acceptable Ad" options. It provides a counter-offer, rather than just "No.", whereby advertisers can feed you unambiguous and untracked ads.

It doesn't matter how saturated the market is. It's takes time to filter out all the candidates. Labour and opportunity cost via delays and distraction

And the thing is, the question of whether to negotiate only comes up if you find yourself in the 1% who get to that stage. It's very expensive for a company to find that 1%, and once they have they don't want to go back to the drawing board, and that's just the tip of the iceberg of your leverage at that point. Of course you should negotiate. What have you got to lose?

What terrible advice. Everyday engineers with a mite of talent have plenty of leverage and should always negotiate. Retaining staff is cost efficient, and real talent is harder to come by than seat fillers.

Thanks for sharing this classical perspective. When I'm kicking off a system for a complex organisation, I start by focusing on what processes/changes occur in the organisation. I find that users can intuitively reason about what they are trying to get done, which leads to clear pipe-functions, from which one can infer and discover correct inputs and outputs. If you begin with a focus on inputs/outputs/data structures, you tend to end up with a lot of disagreement and omissions. The idea is to get to a more suitable Pure Function Pipeline Data Flow sooner.

For an opposing perspective, I cite this article, entitled Process first, not data first

https://scalablenotions.wordpress.com/2015/09/30/process-fir...

How much they have made our lives exist, for that matter!

Tabloid-style headline. Was this in private? It should stay that way (it's nobody's business except those directly affected). Was it public? Media shouldn't be broadcasting his place of work. Will not read.

Very poetic. Provides inspiration to look to our loved ones, find hope and strength in unity to have what impact and what joy we can

> humans wind up resenting the computer...

basis for this assertion?

That is either a problem with leadership, or with the way the role is being framed to them.

Perhaps this will help your case: https://martinfowler.com/articles/is-quality-worth-cost.html

> unit, module, multi-module, and end-to-end.

A great semantic insight.

I still prefer to test complicated algorithms via the external interface. It does end up requiring some scaffolding code for generating inputs based on test cases, but code is for automating repetitive tasks, and they're pretty fast these days, so it's rarely a problem, even for many thousands of test variations. It enables you to test the interactions between your various unit-level variations, which is more likely to catch errors. Again, it also helps make your tests visible, along with the edge cases you're testing, and many times developers working at the unit test level are way more thorough than they actually need to be. Couple this with efficiencies around refactoring and it can actually save time.

Small price to pay?

I'm with Julio on this one. The triangle ought to be a diamond, with the integration tests being the fattest part. This is a level where tests can be at the component level, where they can correspond to specifications which are comprehensible to stakeholders (which helps keep developers accountable to focus test effort on things that really matter), and where refactoring of component internals do not require corresponding refactors of test code. This creates challenges, 90% of which are resolved by applying the same good development practices (re-use, abstraction, performance) to your test code that one is accustomed to applying to application code.

How about this: Code can add value when it's a lot lower quality than we think it needs to be. Customers will pay for even a crappy solution if you are addressing the right problem. Don't over engineer. But also employ staff for the explicit purpose of gradually increasing the quality of codebases which need to continue to churn.