A teammate and I have created a small tool to modify the titles of the trello card in a trello board.

Technical description

It works by applying a function to the existing title (because we wanted to remove a prefix from the existing title).

The modification is done, not through the API, but simulating user interaction:

• Click to edit the card
• Input the new title
• Save

The full code is available here

Conclusion

This has been a great example of working with legacy code, as the tools to work with the existing product are not the ones you would like to have and an imaginative solution provides a way out of the tar pit.

At a client, we’re converting all projects (i.e., sites, services, libraries) from npm to yarn. Mostly for the speed (as it uses the internal cache).

Step by step guide

1. Install yarn in your local environment * https://yarnpkg.com/lang/en/docs/install/
2. Run yarn install * This will create a yarn.lock file * Add that file to the repo: git add yarn.lock
3. Modify Dockerfile * Install yarn (in the Dockerfile). Idea: shortcut this execution with yarn --version in case it is installed * Configure the PATH variable (ENV PATH …) * ADD yarn.lock * Replace npm install with yarn install
4. Modify pipeline * See example (below) * install_yarn. Idea: shortcut this execution with yarn --version in case it is installed * Replace npm install with yarn install
5. Test it

Jenkins

Build step: execute shell

function install_yarn {
  yarn --version || curl -o- -L https://yarnpkg.com/install.sh | bash
  export PATH="$HOME/.yarn/bin:$PATH"
}

install_yarn

yarn install

¿Volver?

I’ve read this article by Raul Avila comparing the options between working in the UK and in Spain (where he’s originally from). Inspired by other professionals (e.g., David Bonilla, Jerónimo Palacios).

Tags: spanish, jeronimo-palacios, david-bonilla, expat, comparison, raul-avila, united-kingdom, spain

Donkey code

I’ve read this article by Einar W. Høst in which he introduces the concept of a ‘missing domain term’ with the example of a donkey being ‘closely related to a horse, though not exactly the same’

Tags: einar-host, donkey-code, ddd, domain-driven-development, domain, abstraction, missing-abstraction, business-logic

10 Habits That Change Boys Into Men

I’ve read this article by Benjamin P. Hardy on why some men are still boys (e.g., expectations from society) and what can boys do to turn into men.

Tags: benjamin-hardy, psychology, learning, evolution

On Sabbaticals

I’ve read this article about sabbaticals by Ian Malpass. In it, he explains why we need sabbaticals, how to take them, and some details about them.

Some principles:

1. If you think you can’t take a sabbatical, you need to take your sabbatical.
2. Day-to-day work pushes us to think tactically; sabbaticals push us to think strategically. Both are valuable.
3. Do the work to gain confidence that you can be away, and then trust that that the mechanisms you put in place are good.
4. Just because your team can function without you, doesn’t mean they want to.
5. There is rarely a good time to leave work for an extended period of time - don’t let this stop you.
6. Allow room for serendipity, the unexpected, and exploration.
7. Plan for your return before you leave, to avoid worry.
8. The sabbatical process doesn’t end after six weeks.
9. You don’t have to be unhappy or frustrated in your work to go on sabbatical.

Tags: sabbatical, ian-malpass, team-management, career

My favorite command-line utilities

I’ve read this article by Vitaly Belman in which he explains his curated list of utilities for the terminal

Tags: vitaly-belman, terminal, cli, application, utility, tig, git

Three Common Mistakes of the First Time Tech Lead

I’ve read this article by Patrick Kua, in which he explains what are the anti-patterns (or mistakes) of a tech lead. They do not only apply to first timers, but more experienced ones as well.

I especially like a comment:

Take all blame and give all credit: I ensure I always take the blame from the stakeholders when something is broken but when they praise, I say its all my teams efforts and I am just guiding them.

ravensnowbird

Tags: patrick-kua, tech-lead, leadership, team-management, mistake

Sentimental Versioning

I’ve read this article (unknown author) on alternatives to semver (semantic versioning).

Tags: semver, semantic-versioning, sentimental-versioning, humor, parody

Devoxx 2015: How to Become a Java Champion

I’ve watched this interview to Arun Gupta in which he explains what is a Java champion and how to become one.

Tags: interview, arun-gupta, java-champion, devoxx

How Can I Become a Champion Programmer?

I’ve read this article by Heinz M. Kabutz on how to become a java champion

Tags: heinz-kabutz, java-champion

The myth of using Scala as a better Java

I’ve read this article by Denis Kalinin disproving ‘Java as a better Scala’. He covers dependency injection, database access, serialization.

Tags: scala, java, comparison, orm, denis-kalinin, macwire, dependency-injection, serialization, database, myth

The eigenvector of “Why we moved from language X to language Y”

I’ve read this article by Erik Bern on the statistical analysis (based on people writing blog posts) of moving from language X to language Y.

This can help predict which languages will be more prevalent in the future.

Tags: eigenvector, statistic, erik-bern, language, programming-language, java, c, cplusplus, go, python

Facebook’s code quality problem

I’ve read this article by Graham King on the problems that Facebook is facing, at the code level, and how they solve some of them

Tags: graham-king, facebook, quality, architecture, code-quality

The key lesson from our serverless migration

I’ve read this article by Gojko Adzic on serverless, a kind of lessons learned. Explains that their system can take 50% more users at 50% of the original cost.

Also explains three ways of authenticating users: use IAM users, use Cognito, pre-sign URLs

Tags: lessons-learned, gojko-adzic, serverless, paas, platform-as-a-service, retrospective, money, total-cost-of-ownership, tco,

When automation goes horribly wrong

I’ve read this article by Gojko Adzic on a story of a manual process that was automated.

Because it focused too much on replacing humans instead of assisting them, MiDAS actually made it more difficult for clerks to access the data they needed for review

This reminded me of the framework vs library discussion:

• in frameworks you relinquish the control, putting your code into the allocated holes.
• using the automated system, you can only check the claim at a certain spot, where the system lets you do.

The system and the framework have been designed to take control of the situation. Both successful at what they do

Tags: gojko-adzic, automation, framework, library, framework-vs-library, comparison, analogy

How I Store My 1’s and 0’s: ZFS Bargain HP Microserver = JOY

I’ve read this article on how Alex stores his backups, using a microserver

Tags: backup, microserver, raid, zfs, backup-strategy

Meeting policy

I’ve read this article by the Ueno team on how they handle meetings. Interesting that they require manager approval for meetings over a certain threshold (more than four people or more than half an hour).

Tags: ueno, meeting-policy, meeting, approval

A Brief History of Random Numbers

I’ve read this article by Carl Tashian on how random numbers have evolved (from dice to pseudo random number generator and random number generators). Explain how some companies that need true randomness (e.g., certificates company) generate them.

Tags: carl-tashian, dice, random-number, randomness, prng, pseudo-random-number-generator, random-number-generator, number-generator, true-random-number-generator

Unlock honest feedback with this one word

I’ve read this article by Claire Lew, in which she suggests to ask for ‘advice’ instead of asking for ‘feedback’ as a way of getting more honest and better responses.

Tags: claire-lew, advice, feedback, feedback-process, improvement

We explore how to use parametrized tests (example in java, example in c#)

The tests are written using mocha syntax: describe, it. Using chai for expectations: assert.

Note: the example used below (adding to an array) is simple enough to be understood by everybody, without having to explain the domain. The real tests can have a more complicated environment or domain. This is just an example.

Using a custom syntax

This is just an example of some possible syntax, not using any (currently) existing framework.

describe('adding to a list', ()=>{
  newTestCase({description: 'to an empty list',
               input: [],
               parameter: 2,
               expected: [2]})
  newTestCase({description: 'to a non-empty list',
               input: [1],
               parameter: 2,
               expected: [1, 2]})

  it(`${testCase.description}`, () => {
    testCase.input.push(testCase.parameter)
    expect(testCase.input).to.deep.equal(testCase.expected)
  })
})

Using an in-place executor

describe('adding to a list', ()=>{
  const runs = [{description: 'to an empty list',
               input: [],
               parameter: 2,
               expected: [2]},
               {description: 'to a non-empty list',
               input: [1],
               parameter: 2,
               expected: [1, 2]}]

  runs.forEach(testCase => {
    it(`${testCase.description}`, () => {
      testCase.input.push(testCase.parameter)
      expect(testCase.input).to.deep.equal(testCase.expected)
    })
  }
})

Using it, DAMP

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  });

  it('to a non-empty list', () => {
    const input= [1];
    const parameter= 2;
    const expected= [1, 2];
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  });
});

Using it, DRY

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    // use explaining variables
    pushingToMatches(parameter, input, expected);
  });

  it('to a non-empty list', () => {
    // not using explaining variables
    pushingToMatches(2, [1], [1, 2]);
  });

  function pushingToMatches(parameter, input, expected) {
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  }
});

Using it, DRY+Fluent

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    // use explaining variables
    pushingTo(parameter, input).matches(expected);
  });

  it('to a non-empty list', () => {
    // not using explaining variables
    pushingTo(2, [1]).matches([1, 2]);
  });

  function pushingTo(parameter, input) {
    input.push(parameter);
    return {matches: expected => expect(input).to.deep.equal(expected)};
  }
});

Sources

• https://rjzaworski.com/2013/01/parameterized-testing-in-javascript
• http://www.adequatelygood.com/Writing-Testable-JavaScript.html
• Example in java: here
• Example in C#: here

(This post is a modified version of the session available here)

WhatsApp Security Vulnerability

I’ve read this article by Bruce Schneier on a security defect in whatsapp, where an ‘unconfirmed’ message can be re-encrypted (with a new key) and resent. This is a vector for some attacks.

Tags: bruce-schneier, security, whatsapp, encryption, attack-vector

Encrypted email service once used by Edward Snowden relaunches

I’ve read this article, by Kim Zetter, on Lavabit restablishing its service. Explains the company’s past and the new services they are offering

Tags: lavabit, kim-zetter, privacy, encryption, email, mail

What Happens When You Mix Java with a 1960 IBM Mainframe

I’ve read this article by David Cassel about the legacy infrastructure of hardware that the U.S. government agencies have. How old mainframes are still useful to web applications and how these mainframes can communicate with more modern systems, through APIs

Tags: mainframe, david-cassel, marianne-bellotti, legacy-hardware, legacy-software, legacy-system, legacy, api

Systems We Love: How the Past Informs Our Present

I’ve read this experience report by David Cassel about the conference “Systems we love”: a mix of papers we love and systems that happened at San Francisco in December 2016

Tags: david-cassel, systems-we-love, papers-we-love, system, conference, experience-report, joyent

The agonizing death of an astronaut

I’ve read this article by Daniel Dietrich on why the implementation of the Option in Javaslang seems to be broken but, in fact, follows the rules of the monads.

Explains why map should be used for non-changing contexts and flatmap should be used for changing it.

Tags: daniel-dietrich, monad, option, haskell, optional, maybe, scala, javaslang

We reverse engineered 16k apps, here’s what we found

I’ve read this article by Fallible team, in which they describe the analysis of apps. They discovered 2500 apps with key and secret on them.

[…] whenever you hardcode any API key/token in the app, think hard if you really need to hardcode this, understand the API usage and the read/write scope of the tokens before putting it in the apps.

Tags: analysis, security, app, key, token, api, fallible

Oh, the emails you’ll get…

I’ve read this article by Joel Spolsky, in which he explains how some companies focus on some metrics for measuring performance, how difficult it is to measure performance.

Tags: joel-spolsky, performance, management, consulting

2002/07/15 - Measurement

I’ve read this article by Joel Spolsky where he explains how measuring performance is difficult, according to Robert D. Austin in his book Measuring and Managing Performance in Organizations. He gives some examples of that, mainly about paying out bonuses for performance reasons.

Tags: joel-spolsky, robert-austin, measuring-performance, managing-performance, book, knowledge-worker, bonus, pay, performance, organization

The Purpose Of Life Is Not Happiness: It’s Usefulness

I’ve read this article by Darius Foroux on what the purpose of life is about: making a difference (even if small) in what you leave behind.

Tags: psychology, purpose-of-life, usefulness, happiness, darius-foroux

The Future of User Interfaces

I’ve read this article by Brandur on how interfaces are becoming more and more bloated, slow and ridden with animations. All of that is targeted to the beginner user, rather than the proficient one. He suggests some ideas on finding inspiration from the terminal applications

Tags: brandur, interface, interface-design, ux, ui

My Increasing Frustration With Clojure

I’ve read this article by Ashton Kemerling on the problems he has found working professionally with Clojure and some possible solutions.

Tags: clojure, language, ashton-kemerling, functional-programming, problem, frustration

Java Without If

I’ve read this article by Ashton Kemerling on how he is using a library called ‘lambda’, which brings some of the functional programming features to Java.

Tags: lambda, library, ashton-kemerling, functional-programming, java, palatable, john-napier

Top ten pull request review mistakes

I’ve read this article by Scott Nonnenberg on the most common mistakes while doing a code review in the context of a pull request.

Tags: scott-nonnenberg, pull-request, code-review, github, diff, listicle

Shutting down Simplicity Itself

I’ve read this article by David Dawson on why he’s shutting down his consultancy company, Simplicity Itself, which was mainly focused on microservices.

Tags: david-dawson, simplicity-itself, shut-down, company, consulting, post-mortem, postmortem

Turn Off Your Cellphone

I’ve read this article by Brandur on how to get more done by unplugging the notifications

Tags: brandur, time-management, interruption, phone, notification

The Dark Standup

I’ve read this article by Alan Brouilette on the steps they took to reduce the amount of hours worked. It started with a few extra questions during the daily standup:

• What didn’t you do today because you stopped working on time?
• What will the impact be on tomorrow because of it?
• How much more time would you have needed to get everything done today?
• What will you do with those hours tonight instead?

and what they realized after a two-week experiment:

• The costs of context switching are much higher than we realized.
• We were spending a lot of time doing things that were urgent but not important, or that didn’t need to have been urgent at all.
• We needed to be a lot more ruthless about saying “No.”
• Some Operations roles are legitimately shorthanded, some of us just needed to impose a little order.
• FOMO WIP (unnecessary work one takes on because one fears missing something) is a real problem, especially as regards to Slack and meetings.
• We worked better in the time we had to work, knowing it was finite.
• Work-life balance improves both work and life. People literally slept better when limiting after-hours exposure to Slack and email. […]

Tags: dark-standup, quote, limited-time, overtime, team-management, experiment, question, alan-brouilette

What it Means to be a Remote-First Company

I’ve read this article by Alyssa Mazzina on what Stack Overflow does to keep its remote employees happy, how they are a remote-first company and small practicalities like tools, holiday gifts and stipends.

Tags: alyssa-mazzina, team-management, remote, remote-work, stack-overflow, team

Google’s not-so-secret new OS

I’ve read this article describing the state of Google’s new operating system, Fuchsia or Andromeda (the final name is not final yet).

Tags: google, os, operating-system, daniel-matte, fuchsia, andromeda

Four Secrets Of People Who Finish Their Workweeks On Thursday

I’ve read this article by Kat Boogaard that includes four tips to finish your week early:

1. They Schedule Intentionally
2. They Focus On Priorities
3. They Tune Out Distractions
4. They Find Shortcuts

Tags: kat-boogaard, time-management, eisenhower-productivity-matrix, urgent-vs-important, important-vs-urgent, urgent, important, productivity

Reflecting On One Very, Very Strange Year At Uber

I’ve read this article by Susan J Fowler on some bad HR practices at Uber and how they are part of the reason their low percentage of women (3%) in the engineering team.

Tags: sexism, uber, susan-fowler, hr, human-resources, women, work-environment, review

Ni dioses ni reyes. Sólo el hombre.

I’ve read this bonilista (in Spanish) by David Bonilla on which he talks about the God Mode and how that is implemented in different applications.

I’ve also liked this:

Los desarrolladores sólo somos herreros que forjan ceros y unos. Construimos herramientas para satisfacer necesidades de nuestros usuarios, sin que eso nos haga mejores que ellos o nos dé el derecho de supervisar y juzgar sus actos. A la hora de diseñar nuevos sistemas y funcionalidades, lo único que nunca deberíamos olvidar es que no somos dioses ni reyes, sólo hombres.

Rough translation:

We, developers, we are only blacksmiths of the digital era. We build tools to satisfy our user’s need, without that fact making us better than they are or without the right to overview what they do or to judge their acts. When designing new systems and features, the only thing we must never forget is that we are neither gods nor kings, just humans.

Las tres erres

I’ve read this article (in Spanish) by David Bonilla in which he explains three necessary factors when considering a job offer:

• Referentes: es imposible conocer a toda la plantilla de una empresa, pero si conoces a dos o tres empleados clave, podrás hacerte una idea de cómo será el equipo que te vas a encontrar. La gente prefiere trabajar con compañeros que compartan su ética y valores. Yo conocía a casi toda la plantilla de Comalatech tras haber coincidido con unos y otros en distintos eventos… y aún hay gente que se pregunta para qué sirve ir a conferencias técnicas si en Internet “se puede encontrar todo”.
• Referencias: es complicado, pero en el día a día una persona puede ser completamente diferente a la imagen que proyecta públicamente. Me ha pasado. Por eso es importante contar con referencias, terceras personas –antiguos empleados, clientes o proveedores- con las que haya trabajado. Los españoles no solemos pedirlas, pero para los anglosajones son un requisito imprescindible. En el caso de Comala, conseguí las mejores de la mejor fuente posible.
• Retos: los profesionales trabajamos por dinero, pero a partir de cierto nivel de salario, podemos permitirnos el lujo de elegir un trabajo u otro según otros factores. En mi caso, siempre he priorizado por encima de todo el potencial de aprendizaje y, en ese sentido, Comalatech no tenía rival.

Tags: referent, reference, challenge, david-bonilla, bonilista, change-job, job-offer

Translation from Haskell to JavaScript of selected portions of the best introduction to monads I’ve ever read

I’ve read this article by James Coglan, introducing monads.

About composability:

The symmetry of the argument and return types is what makes these functions composable

or

symmetric input and output types

Guide to basic monadic functions:

lift, which converts a ‘simple’ function into a debuggable function bind, which converts a debuggable function into a composable form unit, which converts a simple value into the format required for debugging, by placing it in a container

The basic definition:

So what is a monad? Well, it’s a design pattern. It says that whenever you have a class of functions that accept one type of thing and return another type of thing, there are two functions that can be applied across this class to make them composable:

There is a bind function that transforms any function so that accepts the same type as it returns, making it composable There is a unit function that wraps a value in the type accepted by the composable functions.

Also:

[I]t’s a very useful design pattern to be aware of because it helps you spot accidental complexity: code that isn’t dealing directly with the problem at hand, but which is dealing with glueing data types together

Tags: monad, monad-explanation, haskell, javascript, james-coglan, bind, unit, lift

You Could Have Invented Monads! (And Maybe You Already Have.)

I’ve read this tutorial by Dan Piponi, in which he slowly introduces monads, using examples from everyday life.

Tags: dan-piponi, monad, monad-explanation, haskell

Monads, part one

I’ve read this article by Eric Lippert, in which he describes monads as a design pattern that “can sneak up on you”

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part two

I’ve read this article by Eric Lippert, in which he describes monad examples in the C# code. Also describes what an ‘amplifier’ is. I relate it to composing behavior.

An “amplifier” is something that increases the representational power of their “underlying” type.

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming, amplifier

Monads, part three

I’ve read this article by Eric Lippert, in which he describes how to wrap a value in a monadic wrapper (unit)

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part four

I’ve read this article by Eric Lippert, in which he explains the second function (bind)

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part five

I’ve read this article by Eric Lippert, in which he explains the three laws, which are later compressed into two (unit and bind)

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part six

I’ve read this article by Eric Lippert, in which he explains the logical identity of applying the function inside a monad and outside a monad.

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part seven

I’ve read this article by Eric Lippert, in which he states the three laws of monads:

• Applying the construction function to a given instance of the monad produces a logically identical instance of the monad.
• Applying a function to the result of the construction function on a value, and applying that function to the value directly, produces two logically identical instances of the monad.
• Applying to a value a first function followed by applying to the result a second function, and applying to the original value a third function that is the composition of the first and second functions, produces two logically identical instances of the monad.

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part eight

I’ve read this article by Eric Lippert, in which he describes the monad terms he was using other, more common names (unit and bind).

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part nine

I’ve read this article by Eric Lippert, in which he creates a Tainted monad, which is basically a Nullable or Maybe monad

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part ten

I’ve read this article by Eric Lippert, in which he describes Where (as the query syntax form) using the bind signature

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part eleven

I’ve read this article by Eric Lippert, in which he describes the “additive monad”:

• There is a zero value of every construction of the monadic type.
• There is a way to add two monads with the same underlying type together.
• The zero value is the identity of the add operation.
• Using bind to apply any function to the zero produces the zero.
• Using bind to apply the function a=>zero to any M<A> produces the zero.

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming, additive-monad

Monads, part twelve

I’ve read this article by Eric Lippert, in which he explains how the SelectMany could be implemented (but it is not implemented in practice)

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming

Monads, part thirteen

I’ve read this article by Eric Lippert, in which he suggests reading a similar article on the Task comonad

Tags: eric-lippert, monad, monad-explanation, c-sharp, functional-programming, comonad

Tasks, Monads, and LINQ

I’ve read this article by Stephen Toub in which he explains the comonad Task.

A comonad:

[…] dual of a monad, a triple consisting of the type and two operators: Extract (the flip of Unit/Return) and Extend (the flip of Bind)

Tags: comonad, monad, monad-explanation, stephen-toub, c-sharp, functional-programming

5 Questions Every Unit Test Must Answer

I’ve read this article (titled as a listicle) by Eric Elliot about unit tests:

• What are you testing?
• What should it do?
• What is the actual output?
• What is the expected output?
• How can the test be reproduced?

Tags: eric-elliott, javascript, unit-test, test

Why You Should be Planning for 2018, Not 2017.

I’ve read this article by Benjamin P. Hardy on motivation, planning and designing your life.

Some quotes:

[…] having the power to make choices:

• The right to choice
• The responsibility to choose
• The results of choice

[…] hope reflects your perceptions regarding your capacity to:

• clearly conceptualize goals
• develop the specific strategies to reach those goals (i.e., pathways thinking)
• initiate and sustain the motivation for using those strategies (i.e., agency thinking).

[…] motivation involves three components:

• the value you place on your goal
• your belief that specific behaviors will actually facilitate the outcomes you desire
• your belief in your own ability to successfully execute the behaviors requisite to achieving your goals

Tags: benjamin-hardy, motivation, life, planning, long-term-plans

Get 5% Better

I’ve read this article, in which the author explains how compound interest does not only apply to investing and saving but also personal improvement.

Tags: kaizen, personal-improvement, compound-interest

Hunter S. Thompson’s Letter on Finding Your Purpose and Living a Meaningful Life

I’ve read this letter from Hunter S. Thompson to his friend Hume Logan, containing advice on living your own life: must find your own way, decide between floating or swimming to your goal and strive to be yourself.

Tags: hunter-thompson, hume-logan, advice, psychology, life

The Japanese philosophy of Kaizen offers an effective, manageable way to achieve long-term goals

I’ve read this article by Thomas Oppong on kaizen, or continuous improvement, and how it applies like compound interest to your life.

Tags: kaizen, continous-improvement, thomas-oppong, compound-interest, life, psychology

Preparing for a Software Interview

I’ve read this article by Alvaro Videla on interviewing technical people.

Tags: recruitement, interviewing, interview, alvaro-videla

Why Recursive Data Structures?

I’ve read this essay by Reginald “Raganwald” Braithwaite, on which he introduces the relationship between data structures and algorithms. Explains how the algorithm can be split into parts, following the data structure.

Uses a library containing a function called multirec for recursion:

• a candidate library, in haskell
• another candidate library, in javascript

Tags: reginald-braithwaite, recursive-data-structure, quadtree, javascript, functional-programming, essay, data-structure, isomorphic, tree, multirec, linrec, tailrec, haskell

Leading by Example

I’ve read this article by Jeff Atwood on how the best leadership comes from doing, rather than telling how to do it. From being a leader rather than being a boss.

Suggests further reads.

Tags: leadership, team-lead, leading-by-example, jeff-atwood, gerald-weinberg

Discipline Makes Strong Developers

I’ve read this article by Jeff Atwood on a project sucess should not be attributed to a language or framework, but to the team’s and individuals’ discipline.

Also explains how small projects require different levels of discipline than large projects.

Tags: leadership, discipline, nasa, code-complete, coding-horror, jeff-atwood

Effectively Integrating Into Software Development Teams

I’ve read this article by Dennis Forbes about authority and discipline in a team.

One organization’s Enterprise solution is another organization’s short sighted mistake.

Tags: shiny, dennis-forbes, discipline, authority, psychology, politics