This is the first post that has a few notes from our first meeting on Tuesday, 2 April 2019 at coho.
Actually, before I go into what we have touched, I wanted to drop two links about topics I wanted to bring up, but didn’t get the chance to do so:
- The Sleeping Dragon Has Awoken, And Is Filled With A Terrible Resolve – an article explaining the future of RubyMotion. The tl;dr, the team becomes stronger, and will open source RubyMotion as DragonRuby. There’s also a plan to add Windows as one of the target platforms.
- Visual Studio 2019 Launch: Not your average keynote – YouTube — This is a nice video with Scott Hanselman going around the Microsoft campus asking folks about the new shiny features of VS 2019.
Things we have touched
I started listening to podcasts again. What drives me back to that habit is a new walking routine to and back from my office. That’s 10km in total, so plenty of time to listen to podcasts and audiobooks.
What drives me nuts sometimes is the quality of some of the podcasts. It’s usually when there are guests at the show. The host has a great sound quality because they have optimized their setup. The guest though has a really crappy sound quality. Whenever they talk, and you happen to be in some noisy heavy traffic road, you don’t hear anything.
Sitting all day
All office, IT, programming/designing/devops/you-name-it professions have a big negative side. You sit all day, almost still. That has a detrimental effect on our health.
How do you overcome that? Walking, doing some sport, improving your ergonomic environment (like standing vs sitting), what else?
I have found walking or biking to the office helps because it’s part of commuting. It’s not a chore like finishing your work, and still having to go out to do something about standing still all day. That needs extra motivation.
Sure, one would think not dying early is a strong motivator. Unfortunately the results of not moving don’t come immediately. When you see them, it’s almost too late or at least hard to reverse.
What else do you do to improve the situation?
On being at the office vs being remote
We talked about having a tech lead position, and being at the office. If everyone comes to you, you can’t finish what you are doing. Often heading back home or starting your day at home does wonders. You are able to focus more and get things done.
When you are fully remote though you still have to meet with your team face to face. It’s nice to do that as often as possible. Meeting people in the same space, helps the asynchronous remote relationships in a tremendous way.
It’s not the same when you speak to a handle or even an avatar, compared to having met that person in the same space. Every word you type reads in a different way.
I’ve recently read It doesn’t have to be crazy at work which shows how a remote culture, among other things, can help be calm at work.
So, we chatted a bit about that, and the fact a large number of new or even old projects transition to TypeScript.
We tried to agree on what DevOps is. Not sure we managed to do so. Everyone seems to have a different definition.
I guess things evolve. Maybe what DevOps meant 5 years ago, is different now.
In any case, we’ve mentioned a few interesting things. The discussion started when we wondered if a service that started with a typical metal infrastructure, needs to be migrated over to one of the cloud services out there that hide the metal. Instead of dealing with servers, you deal with resources.
We discussed Terraform by HashiCorp and what it does. From their site, the TL;DR is:
Write, Plan, and Create Infrastructure as Code
HashiCorp Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
As we were diving back in the day, and first principles, I took a note of something that is useful no matter what you do:
Always document your decisions. Document the alternative plans you have discussed and why you have rejected them. Why did you decide a specific plan? It will save you great pain in the future when you will not remember anything about why a decision was made.
This is usually triggered by a new person joining, and starting questioning the status quo. I believe we should question the status quo. It’s also good to know how to answer the questions. Why did we choose to go down a specific direction? What were the alternatives? Does the original decision still make sense? Maybe we should revisit the alternative plans.
We were discussing the merits of knowing what’s happening near the metal when you create your deployment infrastructure. Compared to just using some abstract service like AWS or Heroku. An interesting all times classic question arose. Should you know the metal before using the abstract? Many would argue yes. However DHH argues, not necessarily.
That’s it for now, folks. We’ll continue this experiment once a week for the rest of April, and do one blog post per meeting.
Our next one is on Thursday, 11 April 2019, at 13:00, at coho. Again, bring your own sandwich and topics to discuss.
When we have anyone not speaking Greek, we use English.
Please join us. If you would like to RSVP, just shoot us an email.
Have anything to say about our meeting notes here? Please do so in the comments below.
Cheers for now!