computer

mind as water as programming

There is a natural conflict between youth and programming. Frequently the best programming ideas, like in mathematics or chess, come from young people. Sometimes under 30. And in my experience focus becomes harder as you age. Young people don’t know what they can’t do and this often allows them hit the ball out of the park! A very good thing indeed!

The contradiction is the young guns with the fresh mental horsepower have the least experience and frequently charge around randomly between the latest cool “philosophy” and “tool” making less progress than an older programmer who might quickly determine what to avoid. And youth can sometimes be unwilling to compromise the reality of programming economics (code actually runs on hardware I’m told) and the beauty of full normalization. (Hint: your college prof was wrong. Talk to an experienced dba and she will speak the truth. Normalization is a goal like reaching the axis on an exponential curve.)

Currently I am trying to catch up with my team on Python and Django (they have really left me in the dust at the moment) I enjoyed this quote from DRY:

My biggest programming headaches have always come from abstractly struggling with “how can I write a good general solution to this problem”, even though I only know of one place where it’s definitely going to be used. “I’d better think of a general solution now,” I think, “or I’ll have to copy-and-paste-and-change code!” But it’s absurd to try to come up with a general solution without knowing more about the different varieties of the problem that exist (or will exist) in the system.

It’s a battle of two really strong urges - OnceAndOnlyOnce vs avoiding Premature Generalization. Do I duplicate for now and try to live with the duplication for a while, or violate YagNi and come up with some half-cocked generalized solution? It’s a tough one, because almost all programmers hate duplication; it’s a sort of primordial programming urge.

However, even though CopyAndPasteProgramming can be expensive to clean up, so is a botched “general solution” – and copy and paste is far cheaper up front. So I also am in favour of temporary duplication, to be refactored when you have a clearer view of the situation. – MatthewBennett

In our shop I have always called it “do it once for all time for all users.” But it means the same thing. Repeating yourself and not solving issues at the root level is a waste of time. I can’t tell you how awesome it is to not have to explicitly declare getters and setters in Python (vs classic ASP where classes don’t even have inheritance.).

Yet there is a catch. At the beginning of a project or approaching a new industry you can’t really do “root cause analysis” because you don’t have any data. To requote the quote above –

However, even though CopyAndPasteProgramming can be expensive to clean up, so is a botched “general solution” – and copy and paste is far cheaper up front. So I also am in favour of temporary duplication, to be refactored when you have a clearer view of the situation. – MatthewBennett

– this balance is the solution and yes it is a bit messy. If the goal of programming is to make a profit then you can’t just argue philosophy without discussing the economics of it. Economics as in money. And economics as in sometimes duplicate code or duplication of data just runs faster on the servers, increases your search engine rankings and lowers your operating costs. I can live with a bit of duplication for that reward.

Often the best solution is to collect data and slam it together and then identify the best organizational structure before the corpus gets too large. Programming classes or actual data both. A filing system for terrabytes of photos and videos for example. It is a balance between the default import settings of all of the hardware you use and the need to compartmentalize source and work product for portability and backups. Yes, you have to compromise to the machines somewhat because you can’t change the settings on every other camera in the world.

Let the data build up a bit. Don’t fight the hardware. Live with some duplication. Then generalize and normalize as best you can. Balance. “Mind as Water” as Lee would say.

gms

goldman-sachs’ toxic culture

From the article: Exec slams Goldman Sachs and the original Goldman Sachs Op Ed in the NYT:

“I can honestly say that the environment now is as toxic and destructive as I have ever seen it,” wrote Greg Smith on his “last day at Goldman Sachs,” capping 12 years with Wall Street’s gilded firm.

and

“It makes me ill how callously people talk about ripping their clients off,” he wrote. “Over the last 12 months I have seen five different managing directors refer to their own clients as ‘muppets,’ sometimes over internal e-mail.”

and

When the history books are written about Goldman Sachs, they may reflect that the current chief executive officer, Lloyd C. Blankfein, and the president, Gary D. Cohn, lost hold of the firm’s culture on their watch. I truly believe that this decline in the firm’s moral fiber represents the single most serious threat to its long-run survival.

To be fair, here is part of Goldman Sachs response:

In a company of our size, it is not shocking that some people could feel disgruntled. But that does not and should not represent our firm of more than 30,000 people. Everyone is entitled to his or her opinion. But, it is unfortunate that an individual opinion about Goldman Sachs is amplified in a newspaper and speaks louder than the regular, detailed and intensive feedback you have provided the firm and independent, public surveys of workplace environments.

While we expect you find the words you read today foreign from your own day-to-day experiences, we wanted to remind you what we, as a firm – individually and collectively – think about Goldman Sachs and our client-driven culture.

 

Toxic cultures are bad. Don’t talk bad about your clients. Business 101 stuff.