throwaway201606

I appreciate this clarrification comment: had originally read this as option B and was wondering "why would they say this?"

In software dev, for a big finance corp

I like your comment, want to try to expand on it

Comment long but there is a TL;DR at the bottom

My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices

1) explicit internal requirements - core of how the how the app should work towards achieving your business objectives - code expresses what should be done and to a pretty large extent, why it should be done - from business unit requirements - we are building a tool to do “X”

2) implicit internal requirements - core of how the how the app should work towards achieving your business parameters and constraints

eg profit = selling price - ( total of costs )

  - code expresses what should be done but really can’t express why. At best it is in the comments 

eg if market is EU then tax = 30% (or some value for a table), AI can see what is being done but rationale is not explicit

3) implicit internal requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)

4) implicit external requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments

eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done

These come from partners, regulation, compliance, auditability etc

So, my theory

AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)

It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it

As long as you focus on implicit stuff, you will be fine for a little bit

TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev

"Sure, but the difference between one particular formulation of mineral oils and another cannot possibly be that important to the formula."

Formulation matters and is very important.

A1 jet fuel, propane, regular 87 gas and vaseline are four different formulations of some version of mineral oil (petroleum).

Which do you want in a car you are driving? On your parched lips? In your plane engine? Coming into your kitchen stove?

They stop growing a full amount of low value subsistence crops needed to survive and start growing cash crops on some portion or on all of the land. Those cash crops have a higher value.

An example - say you have 4 acres of land and have a family of 4.

In the old world, say you needed one acre per person to grow enough food to the next crop harvest. This would be something like corn or potatoes that can keep. So all your land goes to growing food to survive and you cant make any money.

In the new world, with irrigation, you can do much more - say for the sake of argument, 4 times the crop, in the same space. Now, you only need 1/4 of an acre per person or an acre for everyone. So you grow vegetables that sell for 10 times as much on the 3/4s of land you have that you no longer need to use to survive.

Or even better, you grow high veg on the entire piece of land for income and use the cash to buy your corn and potatoes or whatever as you need them.

Just as all other commercial farmers do across the world.

In other words, solar allows them to become small business owners.

just saw your answer - we are thinking exactly the same thing but I took the long-winded route to saying it

Me: let's watch the animation to see this in action ...

sees: "an uncursed food ration"

This is wild; I gotta start playing text based games.

The piece is good but I think the primary segmentation is not 'useful' vs 'valued', it is strategic vs. tactical.

The author actually realizes this but did not nail this idea to the church door as part of his manifesto.

      >Being valued, on the other hand, means that you are brought into
      >more conversations, not just to execute, but to help shape the
      > direction. This comes with opportunities to grow and contribute
      > in ways that are meaningful to you and the business.

The first part is not being 'valued'; this is being a 'useful strategically'.

The second part - "opportunities to grow and contribute in ways that are meaningful to you and the business." - that is being 'valued strategically'

      > Being useful means that you are good at getting things done in a
      > specific area, so that people above you can delegate that
      > completely. You are reliable, efficient, maybe even
      > indispensable in the short term. But you are seen primarily as a gap-filler,
      > someone who delivers on tasks that have to be done but are not
      > necessarily a core component of the company strategy. “Take care
      > of that and don’t screw up” is your mission, and the fewer
      > headaches you create for your leadership chain, the bigger the rewards.

The first is not being 'useful'; this is being a 'useful tactically'.

The second part, "Take care of that and don’t screw up” is your mission, and the fewer headaches you create for your leadership chain, the bigger the rewards." is being 'valued tactically'.

So, the theory is every member of staff is dropped BOTH a 'useful' and 'valued' bucket for tactical work and for strategic work.

ie: - one can be useful or not useful for strategic or tactical work or both - one can be valued or not valued for strategic or tactical work or both

A couple of counterpoints:

1. You can,unfortunately, be useful strategically and not be valued. Think about the hachet man every leader of a large organization has - the guy who does the layoffs. That slot is useful strategically but can be filled by almost anyone - it is not valued by the org.

2. You can, fortunately, be useful tactically, useless strategically, and be be very very valued in an organization. Best examples of this are folks who are very very good at running operations. Think about a good truck dispatcher, or a 911 operator or an air traffic controller. 90% of their job is effective tactical execution - dealing with this emerging situation right now effectively and efficiently. That is highly valuable to organizations.

Also note that every org needs strategy people and tactical people for long and short term.

One is not better than the other. They are just different.

And there are lots of very highly paid tactical roles, sometimes better paid, that are more challenging and more interesting than any strategy role.

These tend to be "do this or fix this thing right now efficiently and effectively" jobs.

For example, almost any practicing medial role is a tactical one - ER doctor (fix this sick person right now) or controllers for real time stuff - concert and live TV producers (make this thing look good right now), air traffic controllers (keep these planes safe right now) etc etc.

So, net net, pick you spot - tactical vs strategic or both, useful vs. valuable or both - get good at it and then may the odds always be in your favor.

I would think that anyone working in a sewer inspection van would keep the door open because it is highly likely that sewer inspection vans smell like, well, sewer.

I think they have to be long lived else they cannot make sense for performant testing. ie they are created as DB objects, using DDL, in the same way tables, views, functions etc are made.

They can certainly be created at test run time but that would slow things down a lot - you would essentially be creating a ton of objects every time you run the test which means having a setup to test if they exist or not, take them down if they do or fix them if they don't match spec ( e.g. column and data type changes etc etc )

The more I think about this, the more complicated I realize it would be to manage this dynamically:

You essentially have to build a test harness enviroment that figures out your testing elements dynamically from your data environment (with some kind of parameterization engine and data set to tell it what to look for so as to "make functors and run them" (e.g. all PKs of FKs or all columns starting with a certain prefix or all columns of a certain data type etc etc), gets the most up to date definitions of those elements from system tables and uses that data to create or update or drop functor objects ... wow, ok, this is getting complicated, I am going to stop now before I see the void.

OK, this I understand, that is a good insight - cursors are row-processing based so its gonna be slow

I think Netezza, SQL Server and Oracle are all cursor-based processing "by default" so this makes a lot of sense. I suspect that they all have bulk operation capability but can't immediately think of how I would have worked bulk processing in a way that maps to this article - maybe something like analytic functions like windowing, partitioning etc. that is definitely not row by row.

Having said that, the examples I see for actual testing in the article are DQL / DML so would be multiple row processing by default .. yes, the functor definition / creation is a DDL process but it is a "do once and reuse the definition" thing (like, the author correctly observes, a view, which is the point of functors) and the functor in use would just be DML. In which case, functors go back to looking like stored procedures...

I also understood composability as being built in for SQL - for example, in Oracle, packages allow composability of stored procedures, triggers, sequences etc allow composability of DML and views allow composability of queries and tables - which the author points out in the article.

With functors, DDL, DML, DQL, DCL, TCL would still be the only command tools available unless a new command language was invented for SQL for testing - let call that something like DTL (Data Test Language), with a whole new bunch of associated new SQL keywords, capability and functionality that are built right into the core of the DB engine that are optimized for what functors are trying to achieve.