I have spent a few spare moments in the last week looking at Rust, a relative new language.
With the kids on Easter break and naturally requiring frequent attention, and a few brief actual paid client work, I have not had as long uninterrupted time focused on Rust as I would have liked. But I have managed to knock together some basic code.
Rustic Pizza
I created github.com/flurdy/rustic-pizza as my playground with rust and various web frameworks. It is very basic code and I expect I will be quite embarrassed by it in just a few months but it is a start. Rustic pizza will eventually contain several very basic web applications each in a different Rust web frameworks, all for ordering pizza. The pizzeria is a concept that I have created many times over in Java and Scala as an example for piece of framework or similar, some of which I have documented on my flurdy.com website.
Experience so far
So far I have found Rust interesting.
It perhaps use a bit too much of lazy abbreviated names for its keywords, primitives and core methods than I feel is reasonable, but that is me being pedantic. The ownership transfers, lifetimes and everything by reference is a bit of headfuck, but I think I got the hang of it. Rust does also have some of the monadic traits I am comfortable with from the Scala world, though its Futures seems to be somewhat in its infancy at the moment.
Install Rust
Rust can be installed in numerous ways, including via Brew for both Rust and Cargo, its build tool. But I recommend using Rustup, rustup.rs. Rustup lets you toggle between release and nightly version of Rust, and some frameworks require nightly builds.
Learning Rust
The main Rust website, rust-lang.org, is a good place to start to learn about Rust. Especially the "Rust book", https://doc.rust-lang.org/book/README.html, is a great source to learn about basic Rust concepts. Further reading at rustbyexample.com/index.html and aturon.github.io was very useful. As well as various blogs on Rust such as hoverbear.org and hermanradtke.com.
Once you start coding I also recommend the standard library documentation, doc.rust-lang.org/std/, to find out what methods are available, e.g. does option have map, and what is getOrElse called in rust (unwrap) etc.
Web frameworks
As I most of the time create web services or full webapps an important part of my interest is which web frameworks are available. Fortunately the Rust community also recognise the importance of this, so www.arewewebyet.org and github.com/flosse/rust-web-framework-comparison are great information on which frameworks and libraries are available with Rust.
This lead me to take a look at the newest kid on the block Rocket, rocket.rs. So far Rocket have worked very well for me.
For my Rustic Pizza I plan to also take a look at Iron, http://ironframework.io, as it is the most popular Rust web framework on github. Though it has not been updated as much lately compared to Rocket.
Hopefully if time allows I may get to look more in depth into Nickel, Conduit and Rustful as well.
Keep rusting?
Whether I will keep using Rust time will tell. Core Rust concepts such as ownership, references, memory management etc are not aspects I care to manually control and think about too much as I hope a compiler and garbage collector optimises and handles those for me. But I will keep at it so maybe Rust will accompany if not replace Scala as the main hammer in my toolbox some day.
Pair first
Think pair programming first by making it default for all tasks, not the optional occasional pairing which is how most places fake pairing.
Why pair
I have already ranted why pairing is so beneficial in "Pair up now". I have since worked in pair-always teams for another two years and really can’t fathom the waste of not pairing in any future projects.
Don’t do optional pairing
Many places, and I used to work at a few, do optional pairing. They say they pair occasionally as and when the team members think they want to.
I call this fake pairing. As it does not happen very often, and is more like as a second opinion or help when someone gets stuck on a task for a short time. That is not what pairing is. Please read the blog post mentioned above what pairing actually means. (code quality, knowledge share, low bus factor, best practices, egalitarian technology, feature speed)
Optional pairing lets people find excuses to not pair even when they think the tasks may be more suitable as a pairing tasks. Or wait until people are available which is wasteful as well as context switch cost for the other temporary pair member.
Optional pairing is better than no pairing, but only slightly.
Default to pair
By making it default you avoid discussion if one should pair or not. It is less ambiguous and the team just gets on with the tasks straight away. You realise most tasks can be paired on.
You also then start to see the big benefits of everyone pairing over time. You will start to notice higher quality code, that less bugs creep through and the code start to be quite lean as unnecessary code does not even get written. And the flow of tasks is steady as there is less bottlenecks of people with sole knowledge of some part of the system as the knowledge is spread across the team
You will have a team that knows each other better, that really work as a team. A team that has shared their own ideas and niche knowledge of technology. The code base now also looks more homogeneous and evolved as the team has improved their abilities unilaterally.
Non pair tasks
Sure as mentioned in my previous post there are still tasks that does not need to paired on. But there are fewer of these than you think. Mostly research tasks etc can be done alone. Or a pair may not sit together whilst ‘googling’ separately for a bit.
If someone is working solo on a task it is important that these tasks are minimised and time boxed as they often become time sinks and over complicated solutions thought of.
Odd number of team members
Often though through holiday, sickness, meetings, team rotation etc there is an odd number of members in the team making pairing everyone mathematically impossible.
You could triple up on one task. It can be done, though often end up with too many cooks in the kitchen. There may be suitably encapsulated sub tasks that the third triple member can work on his/her own and sync with the others frequently instead.
You could let the odd team member pick up a normal task as an individual. This can also work but I recommend highly against it. Many times I have seen this just result in the problems pairing was meant to solve. They get too entrenched in the task and it takes longer than planned. Or get defensive about it. Or it gets over-engineered. Or they take shortcuts or bad technology choices that would not have happened if paired on.
If there are some obvious non pair tasks to pick up then it might be a suitable filler until pair rotation happens again or a new member becomes available. Tasks such as perhaps some rare support or monitoring, or evaluate some low priority PRs.
Or they can work on some fun but non priority technical debt. Such as automating wall displays, or support scripts or tools to simplify/automate a process. It provides a nice break from the other normal tasks, and also hopefully helps the team in the future and reduces paper cuts.
Don’t chicken out
So do not chicken out by agreeing only to pair when the task's problem is suitable. Instead always plan to pair unless it is a rare hands off research task or similar.
