And today I got this other email from them:
I’m ABC and I’m a Developer Happiness Manager at IJK. I’m really sorry about the miss spelling of your name however I think you style of letting us know was great.”
Nice feedback isn’t it?
Today I received an email from a recruiter that was starting like:
I’m XYZ, the founder of IJK …”
see this GitHub Gist: https://gist.github.com/mattiaerre/005ddfd87af6d159ea96
This “Aha moment” happened to me months ago when I started to read “Flow” by Mihaly Csikszentmihalyi (highly recommended by the way). It helped me to realize why I love TDD and the Test-First Programming approach in general.
Long story short Mr. Csikszentmihalyi describes 8 components of the flow-experience:
- Clarity of goals and immediate feedback
- A high level of concentration on a limited field
- Balance between skills and challenge
- The feeling of control
- An altered perception of time
- The melting together of actions and consciousness
- The autotelic quality of flow-experience: IROI
The last 5 components address the subjective experience during activity in flow while the first three are basic prerequisites.
If you are a developer and you love TDD like me, you should have your “Aha moment” as well. We are talking about Red-Green-Refactor here. That’s it. A clear (and S.M.A.R.T.) goal, a constant feedback loop, a challenge/game that completely engages you, that raises the bar and makes you improve your skills.
This is my description of me doing TDD and anytime I have got the possibility to tackle a non-trivial task with this technique I feel happy and my job becomes enjoyable like a hobby (don’t tell this to my boss though).
P.S. A sincere thanks to GBM that suggested me to read the book; one of the best piece of advice ever!
This is how Mihaly Csikszentmihalyi writes about an autotelic job: “the more a job inherently resembles a game – with variety, appropriate and flexible challenges, clear goals, and immediate feedback – the more enjoyable it will be regardless of the worker’s level of development”. And this part, to me, looks like something you can find in an Agile book. I love Flow and I love Agile. The two are very much connected the way I see them.
Trying to get rid of my C# background when I code in Node.js is quite difficult. One of my favorite subjects in this “transition phase” is, guess what, dependency injection. I believe that this technique is great especially when you are shaping your code using TDD.
My problem is that Node.js is very simple and easy to use and you go straight to the point quite soon without having to manage super overhead; but still I really like to code dividing my logic into components that are interacting with each other. And I need to be able to test them in isolation.
Say I need to handle an HTTP GET request. For sure I need a middleware responsible for handling path and verbs (hapi.js or Express for instance) both are using handlers in order to achieve (more or less) the same result. And afterwards I need to “plug” my components. An application service and a repository for instance; pretty simple.
Now obviously the application service is used by the middleware’s wrapper (lets stay generic). On the other hand the application service itself is going to use the repository that incapsulates the logic of getting data. The chain is: wrapper -> application service -> repository. The dependencies here are pretty clear.
So I would create an application service that at its “initialisation” level (I cannot say constructor here) accepts a repository as dependency. This initialisation routine needs to be managed “by hand” as there is no (at least to me) clear concept of “dependency injection containers” in Node.js.
So I guess that a bootstrap function can be a good idea; but let’s imagine that your applications has got more than 2 components (hard to imagine I know, but still …) would you create a bootstrap script responsible for initialising every single component and injecting dependencies? Probably not.
But still you need to be able to unit test all the components (hence you need dependencies).
So this is my proposal: every component has got an initialiser that accepts dependencies (so that you can unit test your component) but if the dependencies are not injected (hence they are undefined) the component itself decides what to do (e.g. get dependencies using require, instantiating a dependency on the fly, throwing an error).
This is the link to a Gist that (hopefully) better explains what I described above:
What do you think about this?
I’m really looking forward to your feedback!
Entropy is the normal state of consciousness-a condition that is neither useful nor enjoyable.
– Mihaly Csikszentmihalyi, Flow. The classic work on how to achieve happiness
Cat: Where are you going?
Alice: Which way should I go?
Cat: That depends on where you are going
Alice: I don’t know.
Cat: Then it doesn’t matter which way you go.
– Lewis Carroll, Alice in Wonderland
Let’s say you cannot implement Scrum because your client doesn’t really like the idea of sprints (aka everything changes daily). But you are Agile (or you do Agile which is very different, but let’s pretend you are). So you would like to remain Agile without having the possibility to plan too much ahead. So you have got this brilliant idea of using Kanban (so that your client will be able to change his mind quite often). But now there is a problem. If you have got one big Kanban board where you stick every item your client needs you to work on, how do you treat them? Some are XXL some are XXS and still all of them are “kanban” anyway. My idea is the following: some cards are placeholders for a work that requires a separate board so that you can work on a kind of “mini sprint à la Scrum”. Some are just normal cards (a user story let’s say). On top of that I would add swim lanes for high priority activities. Sounds reasonable? I really don’t know.
Running a marathon is tough, running two in 8 days is worse but already planning for the next one is insane. But this is what I like to do so I decided to register for the Warsaw marathon that will take place on Sunday 27 September 2015. I prepared the other 4 marathons that I have run so far following a Garmin Connect plan. I have found it very good as it is taking into account not only the “running” parts but also the “stretching” and the “cross training” ones. The only missing thing for me is, at the moment, indications about paces; in this kind of plans there are only “pace categories” and not “pace with times”. For instance you will only have “easy pace”, “threshold pace” or “race pace” but not actual speeds such as 5:00 min/km or 4:44 min/km. So I have found the My Asics running app where you can create a plan setting, for instance, the day of the event you are training for, adding some info based on your previous runs and then the app is creating for you a calendar that you will be able to follow until your race day and even afterwards (with the recovery phase). This plan is good because it is actually telling you speeds and not just with which kind of pace you should run on any given day. Now the problem is that I run during the week at the gym on a treadmill where the speed is in kilometres per hours while, and any runner knows that, running speeds are in minutes per kilometres (and the My Asics plan has got speeds in this format as well). So I decided to create an AngularJS app hosted on Heroku that does that; it converts min/km to kph so that I will be able to use it when I am at the gym. You can find the app at the following link: https://lit-refuge-5805.herokuapp.com/client/index.html. In the next posts I will share with you some technical info about it.