Recommended Articles - 2016/09/25
I read quite some RSS and articles daily, plus the ones that colleages and friends send or recommend me. Right now the ones I find most relevant/interesting I just tweet them (and they get lost after a while). As I've seen at other blogs (and used to do at a defuct website), I've been thinking about gathering those articles and posting the list among with small comments from me. So, here it comes the first batch, let's see if I keep it up:
- The scarcest resource at startups is management bandwidth: Last sentence summarizes it nicely: "The best teams are hyper focused". Should be read by anyone working at an early-stage startup.
- Command-Query Responsibility Segregation: Talk about CQRS, how relates with DDD, but mostly about why it is interesting to implement this pattern in some scenarios.
- Docker for beginners: Good intro to docker and docker-compose, I think all basic stuff is presented with step-by-step examples.
- On designing and deploying internet-scale services: Good summary full of advices (and the source it's from 2007!). Also, the Internet Scale services Checklist it's a great resource to keep at hand.
- Google Sites Import/Export: I use Google Sites for a personal (internal) wiki, and with Two-Factor Authentication on, there is no official way to export them. This opensource Java tool allows to do precisely that.
- Learning to learn: Free Coursera small course to improve your learning and concentration skills. Highly recommended, won't take you much time and has good tips.
- How I rewired my brain to become fluent in math: About how consolidation through practice and repetition can help you at complex areas like maths (as if you were practicing sports or martial arts). I'm going to try this approach in the near future.
- TomatoTimer and Tomatoi: Web-based pomodoro timer tools. Second link right now has the app broken but hopefully will come back, was useful for sharing your pomodoros with others (like teammates).
Carpe Diem
My father died age 49 of cancer (almost 10 years ago). He worked a lot, partied a lot (newspaper editor, specialized in films and culture, meant frequent night events and the corresponding drinks), travelled a lot, and sometimes also spent a lot on unneeded extras. He was always saying that "money is to be spent". He came from a poor childhood (3 generations of the family living on an attic), with time I've perfectly understood why he valued money just as a means of inmediate happiness.
My mother, nearing 65 now, is going to finally retire in less than a month. Her wishes were to move out of the city, enjoying her dog and maybe going back to the university to study another degree (she has two already). Around one year and a half ago, the dog passed away. And since last year, she hasn't been able to work because she's suffering severe bone and muscle pains at the legs, shoulders, arms... limiting her mobility and making her morning wakes slow and painful despite the medicines. She needs frequent visits to the doctors for the time being, so not only studying is not an option but also leaving Madrid for now is out of question. She's one of the kindest persons I've ever seen, she's worked dead hard, and life is paying her back so unfairly and precisely now that she was going to enjoy a well earned retirement.
Life is sometimes a bitch no matter you're good or bad, and you can never know if you'll be able to fullfil all those dreams you have. It's better to not waste time doing the things you don't like or working a way you don't feel suits you. Friends & family are one of the most valuable treasures we have, not stock options or working at a nice well-known company. I love development and work constantly to improve at it, but I work to live, not live to work.
Don't be a fool and choose wisely what you do with your time, because each second that passes is never going to come back, and you never know when the clock will stop ticking. So carpe diem, seize the day[1].
(Having some rough days because of family issues so thought writing could be of help and also for my future self to remember)
[1] I was actually going to say Carpe diem and fuck bullshit, but some level of BS is unavoidable and tolerable (and easiest way to cope with it is ignoring).
Book Review: Managing Humans
Second, and for now last, book regarding people/team management that I've finished recently. The perfect companion to read alongside Peopleware, full of interesting advices, at least for noobs in management like me. Now, for other topics as the best way to improve is to practice.
Review
Title: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
Author: Michael Lopp
Managing Humans talks about a 20 years of experience manager and his advices, lessons, tips, experiences lived, mistakes done... But written full of humour, jokes and funny scenarios and comments, up to the point that even the glossary at the end is really and worth reading for some geeky jokes. It touches many topics, from pure people management to handling meetings, stressful scenarios, problematic employees, inter-team communications, recruiting, avoiding churn/burnouts, productivity...
I won't get too deep because it covers a specific area, but there it nails it (from my humble opinion), so if you want to improve your team lead skills I think can be really useful. also, you can check my notes below to see some fragments of the content.
Notes
A manager's job is to take what skills his people have, the ones that got them promoted/hired, and figure out how to make them scale.
Manager must haves:
- "speak the language"
- Language of the lazy: Avoid managementese language, use tech language to communicate with your team
- When talking to individuals, talk to them using the familiar language of a friend
- Talk to your team/people often
- Action per decision: Don't just say, do
- Good position in the political food chain
- Able to control when they lose their shit
- Do you have a one-on-one?
- Do you have a team meeting?
- Do you have status reports?
- Can you say no to your boss?
- Can you explain the strategy of the company to a stranger?
- Can you explain the current state of business?
- Does the guy in charge regulary tell you/in public what he's thinking? Are you buying it?
- Do you know what you want to do next? Does your boss?
- Do you have time to be streategic?
- Are you actively killing the grapevine?
- The Update (all clear)
- The Vent (something's up...)
- The Disaster (oh dear...)
- Have three prepared points: To break the ice or have some thread to talk in the first 10-15 mins
- Mini-performance reviews: Change a status 1on1 to a small review
- My current disaster: Chat about a problem you have
- Assume they have something to teach you
- When communications are down, listen hard, repeat everything, assume nothing
- Don't redirect
- Listen, but if doesn't seems to finish (is a rant), close it
- Shut up, listen, wait for the end
- Is not about the issue anymore, it's an employee emotional explosion
- Is the end result of poor management (employee thinks is the only option left to make change)
- Product
- Process
- People
- Pitch
An early organizational chart is a great stagnation warning sign if happens during your version 1.0 lifecycle.
Don't cheat the learning process
Sleep on changes & discussions (let them root)
Reinvent communication and ourselves each time company doubles size
"The curse of success is that we have to move slower"
A flat org is one where power, accountability and responsibility are distributed evenly
If you want to be a good manager, stay flexible, remember what it means to be an engineer, and don't stop developing
When people and teams work together perception of importance changes: There's no shit work when the work is all yours; there's just work you like to do and work you have to do.
Thinking and having ideas:
- In order to create, you need time to think. when you're busy, you're not thinking, you're reacting.
- An offsite day to kickoff is a good start, but you really need to create a thinking-conductive environment in the workplace (where most work happens).
- If stuck on ideas/thinking, write it down, throw it away and write down again.
- People who talk fast, without thinking, might be moving quickly to cover up the gaps in their knowledge.
- An individual tends to be very bad at work estimates until they've begun the work
- Initial step for incidents is information adquisition, not action
- Do always two sweeps to try to avoid mistaks/missing bits. vet the model with at least 3 other people qualified
- Managers don't create product, create process
- A product needs balance between creating predictability (to avoid chaos) and disruption/hacking (to avoid stagnation)
- Maintaining a healthy team: bored people quit. team is full of people who aren't you
- A team lead's job is not only building product, but also building people
- Aspects to search for in an interview: technical (strong tech skills/knowledge), cultural (fit, both team and company), vision (likes to change the world)
- Obsessibly protect your people's space and time (let them focus)
- A reorg always happens because of a company change of strategy
Bootstrapping database creation for a microservice in a container
Today I had to build a new microservice which uses PostgreSQL for data storage. Following the containers principle of disposability instead of reuse, I need to provide some bootstrap logic that setups everything needed for this piece to work independantly and assume that each run might be the first run. Also, following the Twelve-Factor App config guidelines I shouldn't store any relevant configuration value in files, but use environment variables instead.
What looks simple in theory is indeed simple when you find a solution, but might not be obvious, so here's my approach. I use Linux createdb command, but as it doesn't allows you to specify the database connection password as a parameter, I use a .pgpass file with the proper permissions to make it work, with the added bonus of only using bash scripting to achieve it.
echo "*:*:*:$DB_USER:$DB_PASSWORD" > ~/.pgpass chmod 0600 ~/.pgpass createdb $DB_NAME -h $DB_HOST -p $DB_PORT -U $DB_USER -O $DB_USER -w || true rm ~/.pgpass
There might be better solutions (I'd love to hear them) but this does the job and is easy to understand.
Book Review: Commodore AMIGA A visual compendium
Title: Commodore AMIGA A visual compendium
Author: Bitmap Books
If I had to pick a single entertainment system to define my childhood, it would be the AMIGA 500. After having an AMSTRAD PC/W with green and black screen, the AMIGA with all those colors, the incredible sound and music, and those devices called mouse and joystick were trully amazing. It defined my eighties and first half of the nineties, so it is hard to not be biased when reading this book.
Through more than 400 pages we'll see full-page, colourful images of many many classic titles, with the company, publisher, year of release, and then either a brief description or one or two paragraphs with info about the game (from its creators usually), some review or other related info. But not everything is a listing of titles, we also have some interviews in between, some of them really interesting to learn how was developing videogames and art for the machine, and a few "company specials" where we're summarized how some of the most known back then companies grew, what where some of their most important titles, and what happened with them.
The book itself is nice, but I'd prefered more consistency: All games displayed with a brief description and then leaving "insider details" for another section, or the company history, or developers/artists interviews. Sometimes you see an unknown game and just an opinion of "well, was a really tight schedule to develop this title!" doens't precisely help know what's about. Something similar happens with images, some games have wonderful screenshots or the main title image, while others have a random screenshot from the intro, a heavily zoomed fragment or artwork that doesn't represents much the game. This is what I really disliked, I'd loved to see an in-game screenshot of every game and not this "artistic approach" that sometimes fails to achieve its apparent purpose of finding representative takes.
Even with my complaints, the book is full of nostalgia and I'd recommend it (unless you have at hand a real AMIGA computer). It could just have been better.
Previous entries