Monthly Archives: April 2014
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.
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.