trevmex's tumblings

Java Coder, JavaScripter, Rubyist, Functional Programmer, Agile Practitioner.

Solarized Dark for Slack

We use Slack at work for intra-office communication. It is a great tool, but I don’t really like the default color scheme. Fortunately, you can customize it (well at least the sidebar).

I like Solarized colors, so I set about making a Solarized Dark Sidebar Theme. Here is how you do it:

  1. Click on your name in the bottom right and open Preferences:
  2. Click on the Sidebar Theme tab on the left.
  3. Click the link on the bottom of the pane that says: Feeling adventurous? You can customize your theme and share it with others.
  4. Copy this line:
  5. Paste the line in the box at the bottom of the dialog:
  6. Click Done.

And voila! You now have solarized Dark colors in your Slack Sidebar:



#Agile2014 - Beyond Budgeting - an Agile management model for new business and people realities - the Statoil implementation journey (Notes)

Bjarte Bogsnes

You can be as agile as you want at your team level, but once your hit the enterprise level you will hit a wall. Scaling agile is hard, and scaled agile might not look a lot like agile at all.

Beyond Budgeting is a methodology to scale an organization without falling into the trap of a command-and-control culture.

Budgets are often a very bad yardstick for evaluating performance. Budgets and traditional management can be a big barrier to improving performance.

The Human Side of Enterprise teaches us that there are two theories of how people get motivated. Theory X and Theory Y tell us that people are motivated with strong control and rules (X) and people are motivated by being given power and freedom (Y).

Beyond Budgeting is all about moving your processes towards a dynamic style and your leadership towards a values-based system.

Statoil explains their system in The Statoil Book

Beyond Budgeting was pioneered by Handelsbanken back in the 1970’s

Beyond Budgeting is NOT no budgeting. You have to figure out how to allocate resources, but it is given a disproportionately large role in business.

A budget is a target, a forecast, and resource allocation. The first step is to separate budgeting into these three steps, and then focus on improving and optimizing each individually.

"Do I have the budget for this?" is the wrong question. Ask "is this really necessary?," "What is good enough?," "How much value is this creating?," "Is this within my execution framework?"

We want to move away from traditional detailed and annual budgets and towards a budget that increases autonomy and flexibility.

We want to make our decisions at the last responsible moment .

Simple is not the same as easy!

Moving towards a more dynamic mode is an attempt to simplify, but it certainly is not easy.



#Agile2014 - I don’t keep my code clean, I just turn the lights off! (Notes)

Scott Dillman

Hey you. Go read Clean Code by Uncle Bob. It is a good book!

You should care about keeping your code clean! It is important for your code to be readable, especially to other developers.

We spend 10x times READING others code, as opposed to writing code.

Messy code, a.k.a. code that is hard to understand and is poorly tested, slows us down. When you have to deal with that type of code you are much more likely to make mistakes. Ramp up time is longer when code is messy. All these factors make it hard for developers to add new business features.

Why isn’t your code clean? - “Good enough,” deadlines, “I didn’t write it!,” “I’ll clean it up later…” There are a LOT of excuses we, as developers, make for writing messy code.

"Management won’t let us do it" is NOT an excuse. If your manager is telling you how to do your work, maybe they should be doing the work.

Leave the campground cleaner than you found it.

Coding standards matter! Make sure that your team establishes a standard.

There are a lot of great refactoring tools in your IDE (IDEA and ReSharper are especially good), take some time to learn them.

Duplication is the enemy (in production code, not tests).

Delete your commented out code. Delete your unused code (you can find unused code with static code analysis).

Don’t abbr. your code

Naming matters, make names that make sense, are descriptive and understandable.

Include “good” comments. JavaDocs are good comments. Bad comments are comments in the code. Comments inside methods tend to be a code spell to extract a method.

Keep your classes small. Keep your functions small. Keep your features small. Keep your X small is generally a good rule.


#Agile2014 - Women in Agile (Notes)

Diane Zajac-Woodie, Doc Norton

Are agile practices guilty of gender bias?

We all have hidden biases that start when we are babies. The goal is to realize they exist to make them not hidden.

There is an empathy gap in our society. We underestimate the failing of people that are going through things that we have not gone through before.

We are surrounded by images of strong successful powerful men, and hyper-sexualized women.

We favor the familiar over the novel. This helps to explain why we are more uncomfortable with conflicted gender roles (e.g. a boy playing with a doll).

The media is a big part of creating this gender bias. Our society trains our girls to be either nurturing or attractive, that is the only options they have.

We learn social norms for gender very early on in our lives. At a very young age, we start to realize the patterns.

We inadvertently teach our girls that they should not be strong, smart or opinionated.

When members of a group are made aware of a negative stereotype they do worse on tests. Just the reminder that the stereotype exists affects results.

Imposer syndrome impacts about 70% to 75% of the population, and it is especially prevalent in women.

When a woman has to get up in front of people, they tend to feel much more uncomfortable taking credit for their own capabilities. To that point, they often don’t ask for their fair share of pay when the time comes as well.

Women are less liked when they don’t fit the female stereotype. This is true for both men and women.

Women are interrupted MUCH more often by men AND women in the workplace.

Men speak 75% more than women do. Having the seat at a table is NOT the same as having a voice.

We have listener bias in the sense that we feel women talk more, but that is not really true.

This bias implies that women’s opinions tend to be ignored more often.

What all this leads to is a diminishing of women in the workplace. We marginalize women, which makes us lose the power of half the population.

When all these biases combine, women get overlooked.

Women pick mentors, men pick sponsors.

Are agile teams different? Does the agile mentality make women more equal? Less? Or the same?

Stop apologizing when stating your opinion.

Using a speaking token can help give more control to team members at to stop people from interrupting each other.

When pairing, women should NOT have to always come over to a man’s desk to pair. It should be equal.

Stop interrupting women (or anyone for that matter)!

Practice gender flipping. Would you say what you are saying to a woman to a man?

Stop reminding women that they are women!

Use gender-neutral pronouns - “they” FTW!