kalecserk

I also recommend this! I usually use the error handling of the language of choice for that purpose and implement the entire functionality returning errors/throwing Exceptions for the not implemented parts, and asserting upon in on unit tests to implement each pending functionality. I write the description on the assert message itself.

Edit: example

     use Psr\Http\Message\ResponseInterface;
    use Psr\Http\Message\ServerRequestInterface;

    class TransferHandler extends BaseHandler {

      public function __construct(Generator $faker, DataStorage $storage) {
       parent::__construct($faker, $storage);
      }

      public function handle(ServerRequestInterface $http_request): ResponseInterface {
       $resource_token = $http_request->getHeader('X-Resource-Token')[0];
       $account_id = $this->storage->account_id_by_resource_token[$resource_token];
       if (empty($account_id)) {
        return $this->responseInvalidResourceToken($http_request);
       }

       throw new \Exception('WIP -> store transaction data here for subsequent query, also issue notification');
      }
     }

With the following test:

public function testTransfer() { $juno = JunoAPISimulator::initialize($this->faker); $repo = AccountCreationRepoResolver::resolve();

     $account_id = $this->createAccountAndGetId(
      $this->merchant,
      fn(DigitalAccountRequestOperator $op) => $op->withProvider(DigitalAccountProviderSelector::JUNO())
     );

     try {
      Executor::execute(new IssueTransferByBankDetails(
       $account_id->toHex(),
       "BRL 12.42",
       $_ispb = '21018182',
       $_agencyNumber = '0001',
       $_accountNumber = '10000368021',
       $_accountType = 'CHECKING',
      ));
      $this->fail('should have thrown exception');
     } catch (\Throwable $e) {
      $this->assertEquals('WIP -> store transaction data here for subsequent query, also issue notification', $e->getPrevious()->getMessage());
     }
  }

I have been working with software development over the last 20 years and agree with that point of view 100%. Software development is the act of learning/researching. The source code we create is not a “product”. I really liked your metaphor of the research institute. Spot-on. Thanks for sharing

The most influential technical book I have read over the past 10 years for sure. The author guides the reader though the process of managing complexity with some intriguing concepts such as "Define errors out of existence" and "Deep modules". I definitely recommend it.

I work on the payments industry and this issue has struk our systems several times. One extra piece of advice is to also consider the compound timeout when there are multiple calls to the same service. I still remember having our system comopletely hang because Rabbitmq was unresponsive. We had a 50ms timeout with Rabbitmq, but that didn’t protect us since we would hit the service 50 times per request.

Humble and didactic, totally agree that we should thank the author. I for one felt compelled to contribute to OS after reading the article.

In a sense, this was a prelude of the modern day IDE. Allowing one to have a bird’s eye view of the project and helping with coding. Loved it!

There is literally a slide titled: `What was we thinking` where Rasmus goes through the most controversial decisions he made while doing PHP. I recommend this talk for anyone, specially because most of us, if we are lucky, will have to deal with a 25 year system at some time during our career.

Great comment, if you allow I would summarize by rephrasing one sentence making it shorter:

What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future.

That is it! Thank you for sharing your thoughts.

> In SQLite, the presence of assert(X) means that the developers have a proof that X is always true.

Almost impossible to prove anything in a sufficiently complex system such as SQLite. The difference between assert and always seems arbitrary IMHO

Great questions. Those will raise the interviewer’s perception about you as well. Source: am hiring manager.

I live in Brazil, we have a special kind of high school that will teach you a craft in addition to your tipical scientific preparation. And Yes, I have graduated from college, studied at night ;)

Hello!

I am currently 36, working for pay as a software developer since 1999, father of three -- and I would like to reiterate oppositelock's comment: "you're being too picky"

I totally understand your frustration with all this "helping other people" buzz but... Ultimately this is the job to be done by you right now :)

About the entire open-office culture, since I am a manager I have been granted a private office - which I have immediately converted into a shared quiet space to work for whoever might need it. I actually prefer to be where things get done.

I really think the problem lies in the engineering culture and maturity of the teams you had the chance to work with. Keep on looking!

Best,

Pretty sure it will get you banned from their services. Source: work with payment systems

Cheers for bringing me back memories of “Spike solution” from the early 2000s :)

http://wiki.c2.com/?SpikeSolution

Totally agree, and this misinterpretation got crystallized into your tools that often recommend/generate tests that are named TestSubjectClassNameTest->eachMethodTest. We have to pay attention to that ;)

I have been working with teams that heavily use automated tests for over 16 years now and, at least on my experience, making others test your code would lead to untestable code and delegation of responsibility.

Even for manual tests, the test spec should make part of the change request and be reviewed appropriately.

Cheers!

> I start with the lowest-level, simple operations. I then build in layers on top of the prior layers.

I was discussing this with a coleague this week: starting by the lower level details vs starting from the more abstract/whole api. I prefer to start by writing a final API candidate and its integration tests and only write/derive specific lower level components/unit tests as they become required to advance on the integration test. My criticism on starting with the bottom-up is that you may end up leaking implementation details in your tests and API because you already defined how the low level components work. I have even seen cases where the developer end up making the public API more complex than necessary due to the nature of the low level components he has written. Food for thought!