Provide a Vision

Self-organizing teams require a vision to make decisions independently. Autonomous teams are only able to succeed if they are aware of business goals. The goals are derived from the commitment to fulfil a measureable vision. The most important part is for the team to know why they do things and why they are committed.

Long term objectives and interactions provide a vision.

You want A players

A Players

  • Can be given fuzzy goals
  • If they don’t know it, they can figure it out
  • Do not complain, if something is unreasonable and unattainable they will just let you know
  • Set their own deadlines
  • Make their own decisions. Want to know what is the vision to be able to make their own decisions
  • Collaborate with others easily, are able to take action, delegate tasks and take directions

B players

  • Need to talk to a 'manager' constantly
  • Always ask for directions and shield themselves behind those directions ("What am I supposed to work on next?")
  • Everything needs to be written down
  • Mostly complain instead of doing work or fixing problems
  • Get frustrated when they are given objectives instead of tasks

Security Benefits of Microservices

Microservices by design have strong boundaries. Having specialized communication protocols allows for transfer of the data in an encrypted tunnel. Since microservices are based on messages, its easy to implement message level encryption, such as encrypting JSON or XML.

Micrososervices should have isolated data stores. This means that no other service has access to that data and therefore we are minimizing the surface area for an attack.

Finally, because of the convenience of the distributed nature of microservices, they can be protected inside special containers blocked from outside connections. This can be further improved by using separate machines with strict security protocols just for dealing with sensitive data.

HTTP Codes in Pain English

I find myself explaining HTTP codes a lot. I love proper status codes, primarily because it allows the client to make appropriate decisions.

Here is a cheat sheet:

200 - All good.
201 - You created something.
202 - I accepted something but will deal with it later (create or delete).
301 - What you want has moved, it is in the following URL.
400 - You sent me something bad, I don’t like you.
500 - I messed up, my bad.

Let the Team do it

The world is moving so fast now-a-days that the man who says it cannot be done is generally interrupted by someone else doing it.—Elbert Hubbard.

Transitioning to agile is hard, specially for people who like having control over others. If your team can solve the problem with a viable solution and enthusiasm, let them do it. Most likely it will be done better than anything that is forced into the team. Never stop people from working hard by telling them it cannot be done, specially if they have a solution they want to try, it will only kill their motivation.

If it fails, the team will learn something and respect you for giving them a chance. In an agile environment, time boxing means failure is not catastrophic.

Goal Setting

I stayed late at work, my very first programming job. It was a goverment job so nobody else was there exempt for me. Around 8pm the Janitor came and asked me what I was doing. Young me said:

"I am doing a little extra work, the fun parts. Afterwards I am going to watch a movie with a friend and eat some pizza".

He asked me if I was happy and I immidiatly said I was extremly happy. He replied that I was one of the lucky ones because I knew I wanted.

He gave me a little tip/trick. He said that:

"To find out what you want to do in life, write down everything that you DO NOT want to do in a sheet. Then take another sheet and write the oposite of what you just wrote."

He explained that most people know what they do not want but have not clue what they want. It made complete sense, also I reliased that this technique is very usesful when trying to find out what others want.

Every four months I practise this excersise to keep me in check.

Congratulations on your Latest Failure

Small failures are a good. People get great when they accumulate a significant amount of failures, that is when growth happens. The only catch is that a failure should not be repeated again, because then, the failure would be a mistake. It is a subtle difference but it is very important.

  • Failure is when a something receives a lack of success

  • A mistake is an error that could have been prevented and usually is caused by misjudgement

Mistakes can be prevented, because we have accumulated enough failures to have better judgement. Therefore, if one faces a failure, one must add it to the bag of tricks, that will prevent it from happening again to avoid a mistake.

Applied Critical Thinking in Graduate School

I believed I was a critical thinker, until I got into graduate school.

The biggest lesson was to question authority. It is a systematic process to clarify goals, examine assumptions, look for hidden values, evaluate evidence, proactively accomplish tasks and evaluate conclusions (Fluid intelligence).

If you do things right, you will be challenging other researchers work. It is a very valuable experience. As long your ideas have reasoning and insight behind them, any good researcher will respect it. It is a good experience because you will be able to learn to talk to authoritative figures, about their area of focus, at their level.

On the flip side, it is always great to have very smart people challenging your assumptions.

CI JavaScript testing in TeamCity - Updated

Updated: The easiest way to get started running JavaScript tests under TeamCity is using jasmine,  karma and phantomjs. We are going to use node.js for our environment, so first install node.js and use npm to install the following dependencies.

You need to install karma:
npm install -g karma

Karma needs a utility to run from terminal, karma-cli
npm install -g karma-cli

A launcher for PhantomJS, karma-phantomjs-launcher
npm install karma-phantomjs-launcher

Finally, install the TeamCity reporter, karma-teamcity-reporter
npm install -g karma-teamcity-reporter

To get you started fast, I have created the following karma configuration file you can directly use. You might have to tweak some paths, what libraries to load, etc.

Finally, I recommend you install a headless browser like phantomJS. make it is available in your path so karma can call it from terminal. If you are using a mac the easiest way is to use brew.

brew install phantomjs

Here is a sample project. For this tutorial I follow this structure under git:

Test that everything works from terminal:
karma start

TeamCity configuration:

Perfect Sit-Stand Desk Setup

Most of us spend a ridiculous amount of time in front of our desk. It makes no sense to have a bad setup.

Throughout many years I have experimented with different setups and I have found one that I enjoy the most.

Ergotron WorkFit-D Sit-Stand Desk

I found a bug

"I found a bug", "There is a problem here", and "This does not work" are things associated with testers doing testing. Developers often forget that it is a part of the testers' job to find problems. Sadly, testers themselves are usually associated with the problems.

The best testers are not there to find problems. They are there to help build quality products; they are part of the team. Working with a good testing team makes you a better developer.

Instead of working against your testing team, work with them.

  • "How are we going to test this feature?"
  • "What hooks, dashboards and logs can we add?"
  • "Which data can be mocked?"
  • "What type of sandbox do we need?"

Retro time

Emotional charged regularly scheduled meetings. Retros: where we all gather in a room and talk about good and bad things that happened. In the end, retros are not important if they are not actions. The most important part is not what happens during the retro, but what people do in between retros.