Watching – Explaining Agile

Explaining Agile – Martin Fowler and Neil Ford at USI

An explanation of agile process. It’s a little old one (at USI 2010, though it’s uploaded last year), but it’s a nice presentation.

Some notes are,

• Traditional Plan-Driven approach is “Plan your work. Work your plan”. It’s about making prediction, and its success is evaluated by if it worked as planned. Plan depends on stable requirements. It’s usually hard in software development, and agile development came into play for addressing this issue. Agile development is taking more adaptive approach for removing this dependency itself.
• Software process tries to fit people as component within the process. However, behaviors of people are not linear, and it’s difficult to predict and be controlled by given process. In the agile practice, people comes first to choose their own process.
• There are two different approaches – defined process and empirical process. Defined process is to convert the input to output using the pre-defined processing method. Empirical process iteratively adjust the output through the feedback loop of the monitored outputs. If there are large unknowns, empirical approach is more suitable.

Advertisements

Pair Programming and Remote Work

LA Ruby Conf 2014 – I Have Pair Programmed for 27,000 Hours: Ask Me Anything!

An interesting type of presentation, which is actually just Q&A whole the time. Most of the audience seems have done the pair programming, but questions were non-stop for 30 minutes. Maybe because, it involves certain difficulties on identifying best-practices.

One major topic is remote pair programming. These days, a lot of tools for remote work are available, and it’s getting easier to communicate. Screen-sharing with video conferencing can be more efficient than working at busy offices with noises and interruptions. Also, GitHub’s pull-request type of communication would be making it easier to collaborate remotely through actual codes, even members are working at different timing.

I don’t have much experience on pair programming, but sometimes I do pair-troubleshooting on certain issues at software development or testing. Mostly it works well on identifying the causes, with the power of another set of eyes. Also, it’s good to avoid going deeper and deeper while keep missing the point.

Watching – How to Become a Better Developer

Kod.io 2014 – How to Become a Better Developer by Markus Prinz

A nice talk on improving the development skills. In sports, taller or muscular people often gets advantages, but, there’s no explicit talents to identify intelligence. One major factor is deliberate practice. As Outliers book indicates, 10,000 hours of practice is required for becoming a expert.

Some key factors are,

Improvement

How to improve is not obvious for everyone. In order to improve, it needs to be either “new” or “hard”.

Repetition

It’s required, but you should not keep repeating the same thing. It needs to be combined with “new” or “hard” point.

Feedback

Having mentor is great for getting feedback. Or, it can be friends or coworker.

Demanding

You have to be concentrated to gain something.

Hard

It involves frustration and failure, but it’s required steps.

Good Goal

It needs to be specific and also the process reaching the goal is important.

Many good programmers pretty much likes programmings and challenges to the new thing. Keep doing it for a long time makes them that way.

Elixir – Spawn Viewer

https://github.com/parroty/spawn_viewer

Playing around the process spawning of Erlang/Elixir. It’s an interesting framework, but I faced some difficulties to understand the concept initially. So, I was looking for a way to visually confirming the behavior and implemented a simple GUI. It’s preliminary yet, and might add more function later.

• It uses Google Chart to show timeline of process behaviors. For easier to make graph, delay is inserted in the spawn processing.
• It uses highlight.js to display Elixir codes.