Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ gherkinnn 10 days ago

Mort is happy with an if soup. Amanda sees what the if soup ought to do and replaces it with a simple state machine and fixes two bugs along the way.

▲makeitdouble 10 days ago | parent [-]

Wouldn't refactoring the if soup into an algorithmically elegant solution what the Einstein does ?

▲layer8 10 days ago | parent | next [-]

Einstein would write a new state-machine library with SIMD optimization for the purpose, and refactor any logic into it that could possibly be contorted into a state machine.

▲binoct 10 days ago | parent | prev | next [-]

As I imagine it, Einstein would no be happy with fixing a couple bugs and making a state machine. Einstein would add a new unit test framework and implement a linear optimizer written with only lambdas to solve the problem and recommend replacing the web server with it as well. This is tongue in cheek but gets the idea across.

▲makeitdouble 9 days ago | parent [-]

Sounds me like what you see in the Amanda type is "balance", landing as Mort mixed with an Einstein.

To quote OP: "None of these personas represent a real engineer - every engineer is a mix, and a human with complex motivations and perspectives"

▲Spivak 9 days ago | parent [-]

The problem is that "work smart not hard" for software devs is counterintuitive because using your brain is the hard work. Einstein works too hard and creates code that's hard to reason about, Most doesn't work hard enough and creates code that's hard to reason about.

The originating example for an Amanda is someone who used her brain to recognize that the existing code was clumsily modeling a state machine and clarified the code by reframing it in terms of well-known vocabulary. It's technically an abstraction but because every dev is taught in advance how they work it's see-through and reduces cognitive load even when you must peel back the abstraction to make changes.

▲earleybird 10 days ago | parent | prev | next [-]

The Amanda solution is the intuitively obvious to even the casual reader. The Einstein solution is quite succinct but takes years to understand all the nuance in the one liner. :-)

I appreciate both for different reasons.

▲makeitdouble 9 days ago | parent [-]

I kinda see the original proposition as similar to a RGB framework. The same way we mix RGB to have a whole spectrum of colors, I assume we can mix Mort, Einstein and Elvis to get whole spectrums of engineers profiles.

There will be people looking at pure Green and pure Blue and ask for an Emerald color to get RGBE instead, but that's not how the RGB framework works. And I can't get rid of the feeling that Amanda is that Emerald color people are clamoring for.

I also kinda get why Microsoft got rid of the system for something more abstract.

▲pessimizer 10 days ago | parent | prev [-]

Elegant is usually the opposite of maintainable. Reading elegant code is like reading a book of riddles (which is one of the reasons we enjoy it.)

▲n4r9 10 days ago | parent | next [-]

True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.

▲pessimizer 10 days ago | parent [-]

I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)

▲n4r9 8 days ago | parent [-]

I guess it depends what mean by "elegant". For me, an elegant solution makes it obvious that certain classes of bugs will not be present.

For example, suppose you have an application that connects to 17 queues and processes a different type of request from each. You could do this in lots of lines as follows:

  var processors = new Processor[18];
  processors[0] = client.CreateProcessor("FooQueue") { Handler = GetHandler("FooRequest") };
  log.Write("Connected to Foo Queue");
  ...
  processors[17] = client.CreateProcessor("BarQueue") { Handler = GetHandler("BarRequest") };
  log.Write("Connected to Bar Queue");
Or you could do this:

  var queues = new List<string> { "Foo", ... , "Bar" };
  var processors = queues.Select(q => client.CreateProcessor(q + "Queue") { Handler = GetHandler(q  + "Request") };
The former - despite being "warts and all" - is more prone to bugs getting missed in development and review.
▲packetlost 10 days ago | parent | prev [-]

Your definition of elegant is definitely different from mine lol

▲Izkata 10 days ago | parent [-]

Yeah, I'd define elegant as something like "unexpectedly simple and easy to understand", relative to the simple approach to the problem at hand.