The Importance of Technical Communities

Technical Communities may be the single most important factor I’ve had (and continue to have) in building my professional career. Yes, that’s how important I believe they are.

I first got involved with communities back in the late ’90s. I got a job where I got to work with FoxPro, which I knew nothing about other than that it looked similar to what I knew at the time: Clipper and dBase. That was also around the time the internet was becoming a thing in Brazil in the days of dial-up connections.

In order to get up and running on the required tech stack, I found online forums in Portuguese.

There were many resources in English for FoxPro, but not a lot in Portuguese. I knew some English at the time. Many Brazilian developers didn’t. So here’s what I did: I’d see people’s questions in the online forums, look up the answers in English on the web, and reply to the posts in Portuguese. Why did I get from doing that?

  • I learned a lot of FoxPro in a short period of time
  • I learned a lot of English
  • I helped other fellow developers

A member of the community invited me for lunch one day and gave me a couple of FoxPro books. I asked the reason for the gift, and he said: “If I help 100 people, maybe one of them will give me a hand in a moment when I could really use some help”. I have taken that lesson to heart and applied it to my life deliberately ever since.

Because I was answering so many questions, people thought I was an expert.

When a new version of FoxPro was about to come out, members of the community reached out to the Microsoft office in Sao Paulo to ask if there was going to be an official launch event. The MS manager said they could do that, but there were no MS employees in Brazil who were well-versed in FoxPro. The community member said, “well, problem solved: I know a guy”. Next thing I know, I’m presenting two full-day, soldout launch events. Attendance included people flying from other states (if you don’t know how big Brazil is, please pick up a map…)!

So that’s how I broke into technical public speaking. Next, I got into writing articles, creating a magazine, organizing conferences in a few different States, organizing study groups, creating training videos…

So much came out of the common need to learn a new tech stack, followed by the simple action of helping others along the way, with however little I knew of anything.

The fact that I’ve been living in the US since 2002 is directly related to this involvement with technical communities.

See why I have a cute fox as part of my office decor? Never forget where you come from!

Also, when some youngsters make smartass comments about the mention of FoxPro on my business card, I may just say: “sit down, kid, let me tell you a story…” 😉

Leave a comment

Building my Book Library

I’m slowly building my book library. I enjoy books in all shapes and forms: paperback, e-book, audiobook, animated book summary, etc. My library reflects that.

Most of my technical books are e-books. I usually get their PDF version and put it in a “Books” notebook in Evernote; its search feature goes into those PDF files to find what I’m looking for. Quick access when I need that information.

My fiction books are either paperpack or e-book (usually in Kindle format).

The non-fiction, non-technical books are well spread out in different formats.

I’ve been reading more and more of my e-books on Kindle (on my iPad), using its features to highlight and comment; I often review my notes and highlights.

I’m getting more and more paperback books. Sometimes, I end up getting them after either listening to the audiobook or reading the e-book versions.

I have books in my library that I’ve purchased over a decade ago and haven’t read yet. I also have been acquiring more books that I don’t know when I’ll read them, but I do want to have them readily available. I don’t ever want to be in a situation where I tell myself “oh, gee, I really want to read something, but I have nothing to read”. Seriously, dude? Just go to your library and pick something up!

When I get book recommendations from friends or from reading other books, I look them up on Amazon and add them to my “books wishlist”, and I add a note to remind me where the recommendation came from.

To keep track of my backlog, books I want to read soon, books I’m currently reading, and books I’ve read, I still use the same process I’ve described in 2016.

2 Comments

“Work-Life Balance” makes me cringe

There are countless of articles and resources out there on “how to improve your work-life balance”. In the last many years, I actually cringe when I hear “work-life balance”. There’s just life. I didn’t use to think that way, though.

I see myself bringing “work-related” things to my personal life: from using Scrum and Agile practices in my own life to leveraging my product and software developer skills to my hobbies. I also bring my personal life experiences to my work.

If I’m in a work situation and I’m interacting with a co-worker who I know share similar passions with me (maybe motorcycles and racing or music), why not bring that part of my “personal life” to my “work life”? We can freely draw analogies from things that light us up and bring us closer to a shared understanding of the business context at hand.

If I’m in a personal situation where things seem to be going out of whack, why not bring in Scrum practices that can help me expose my challenges, see through them clearly, identify ways to tackle them, and stay focused? If I see things in my life I could make better through software, why not do that? If the answer to that last one is “well, because that’d feel like work”, it’d make me believe I don’t like my work. Since I do love the work I do, it’s not “just my work”, it’s actually something I enjoy as I live my life.

There’s a quote out there that goes somewhat like “craft a life you don’t need to escape from”. The practice of writing up annual reviews has been helping me over the years to make sure I “live the life I love, love the life I live”.

In closing, I’ll drop this quote I got from Headspace:

Mindfulness reminds us that any separation in life is artificial. Work-life, home-life, social-life… there is just life. This. Here. Now.

Leave a comment

Virtual Brown Bag: November 2020 Summary

November was a week short in Virtual Brown Bag meetings due to Thanksgiving. I hope everybody enjoyed the long weekend and took the time to feel and express gratitude.

Here’s a quick summary of topics we’ve covered in November.

  1. November 19th, 2020

    Job interviews, Azure Certification, Azure emulator, Node.JS, React Context and Context Provider.

  2. November 12th, 2020

    GitHub hack (youtube downloader), user stories, test organization (1 test fixture per class/component vs context-based), TypeScript (generics, unions, what’s the minimal bar for devs to know), JavaScript ORM.

  3. November 5th, 2020

    Discussion on testing, GPT-3 (AI, neural network), asking about SOLID in interviews, what is good code?

Leave a comment

Xamarin: Gave in, Gave up

Three years ago I decided to try out Xamarin. Given my experience with C# and WPF/Xaml, it seemed to make sense. I spent about 4 hours following some tutorial online and got the sample application up and running. Two months later, I tried to pick it back up: I launched the idea, hit “run”, and got some compilation error that didn’t tell me a whole log. After a lot of digging around on the web, I found out I had to update Xcode. After I did, the error in Visual Studio for Mac went away. Other priorities made me put that all aside for a while.

Last weekend, I gave in and decided to pick it up again. I have an idea for a mobile app that would help me with one of my hobbies and thought Xamarin would be the quickest way for me to get it done. The first feature for the app is a simple to-do list. That’s just a step away from the typical Hello World app, isn’t it?

After 6 hours of struggling, I gave up.

I was trying to use JetBrains Rider as the IDE. I thought of creating a Xamarin.Forms app, as it seemed the easiest way to have my app available both to iPhone and Android devices. I didn’t get passed creating the project, as it kept telling me that the “Android SDK is not installed”, even after installing all the Android things I’ve found out about; things that ate up 20Gb of my disk space, and I still couldn’t create the project.

I then decided to only target iOS: maybe if I at least got the app on my iPhone I’d find motivation to figure the Android deal later.

The project got created and I just tried to run it in the iPhone emulator (I didn’t write any code or change anything). Found some references online about Xcode, made sure to update it, but still, no luck.

Then, I tried to deploy it to my iPhone. First got errors about the Apple certificate needed. My Apple Dev membership expired years ago, so I renewed it ($107!). Got the certificate, then started getting errors about “Provisioning Profile”. Got it created, did what I told to do, as per online resources, and moved on to the next error: [MSB6006] “dsymutil” exited with code 1.

After some research on the error and not liking the answers I’ve found, I gave up. Six hours had gone by and I couldn’t successfully create and run a brand new project.

I’ll be trying Flutter next. Let’s see how that goes…

4 Comments

Know, Say, Do

For several weeks, I’ve had the following written on my whiteboard:

I think I wrote it up after reading this post, Actions, not words, reveal our real values, by Derek Sivers, which reminded me of my own post, stop thinking about and just do it.

I’ve been reading a lot of books. But why? Just to know more? But what do I do with that knowledge?

I can find people who could be helped by the knowledge and say what I’ve learned to them.

Or I can use that knowledge myself and actually do the things I’ve read about. Now, that’s a great idea; I get to put it to practice, gain experience myself, and be even more helpful to others.

I can also do all of those things. Maybe I’ve just read about something that enticed my curiosity, but I’m unsure on how to put it to practice. Well, if I share it with others, maybe somebody else is be able to help me by sharing their own ideas or experiences on the subject (This is one of the things we do weekly at the Virtual Brown Bag, by the way).

Sometimes we may do something before we actually know much about it, of before we say it to others. Sometimes we may say something but never do anything about it.

Knowing is important. Saying (sharing with others) is more important. Doing is even more important. But they don’t always happen in that order.

 

Leave a comment

Hitting the Apex in Scrum Projects

Notice the title doesn’t say Scrum “Software” Projects, because I believe Scrum can be applied to many different types of projects. Having music and motorcycle riding as the other passions of mine, I find myself drawing comparisons and reapplying learnings where I see fit.

In a talk about building trust through delivering results in Scrum software projects, analogies with hitting the apex at a race track have come up, and I felt I had to expand on that idea. So for this post, I’ll consider a software project, but again, the ideas can be applied to many types of scrum projects.

I’ve only started learning about apices and race lines when I started riding a motorcycle at a race track in 2017, so my comparisons here come from my understanding on the subject as of November of 2020. As I learn more, I may need to update this post in the future.

If you’re a fan of races (motorcycles or cars, it doesn’t matter), you are most likely aware that racers know how to hit an apex consistently and why they should hit them.

Consistency is key; hitting the apex consistently, lap after lap is extremely important. Hitting the top speed on a straightway isn’t as important as hitting consistently high average speeds, which yield fast lap times.

Reaching 200mph on the straight and then running off track isn’t the most efficient way to turn fast laps (not to mention you might crash when you run off). Working crazy hours during a Sprint to deliver a high number of story points isn’t an effective way to turn good quality software and keep doing it lap after lap; I mean, sprint after sprint (not to mention you may crash; I mean, get burned out).

The apex is typically the slowest part of a corner. The soonest you can get to WOT (wide open throttle, which means you’re using the vehicle’s fullest acceleration potential), the faster you can get to the next corner. But then, you also need to know that you will have to slow down in order to make that next corner. If you’re looking down to the speedometer to keep marvelling at how fast you’re going, chances are that you will be running off track. If we keep solely looking at number of story points, we may lose track of where we’re going.

In order to find the proper race line, with the respective apex for each turn, we need to analyze each turn backwards. We need to know what comes after each turn to be able to plan a strategy for getting in and out of the corner as fast as possible; if turn 2 is a slow hairpin, then we may never get to WOT coming out of turn 1. If turn 4 preceeds a long straightway, then we need to make sure we exit that corner as fast as we can, getting to WOT as soon as possible.

However, opening the throttle too soon, may cause us to run wide, creating a need to slow down, before accelerating to the full potential (a process that causes loss of precious time).

In a motorcycle, if we open the throttle too much too soon, it may cause loss of traction. Depending on how we handle the situation, when the bike regains traction, it may send us on a trip to the moon and back. Not pretty. How do I see that in a scrum project? Maybe we’re forcing performance optimizations when it’s not the right moment?

Back to planning the corner backwards: we need to see what’s coming. We need to have a vision. We plan for it. Then we execute it (by riding laps). As we do, we look ahead, through the corner.

We may misjudge how much speed we can take into a corner and brake too much. Next time around, we brake a little less.

We may not have good reference points (brake points, turn in points, apex, exit points) around the track to help us assess our speed and strategies. On every lap, we stay aware of those things, so we can fix it next time. Remember sprint retrospective meetings?

Such approach can only work if we are not going recklessly around the track. If we’re riding without control, we will not be able to evaluate our execution; we won’t learn anything from it. So we can’t improve it. We can’t come up with better strategies.

Only hitting the apex isn’t enough. Racers have different strategies for hitting the apex. If they’re trying to make a pass, they may decide to take an early apex, so they can carry more speed into the corner, hopefully passing the other rider, but at the expense of coming out ot the corner slower.

On the hand, if they’re trying to turn consistently fast laps, they may take a late apex, where they carry less spead into the corner, but are better placed to accelerate harder out of it.

See the riders in the photo below: some are trying to pass, some are planning to pass, some are trying to avoid being passed. Their plan to hit the apex varies based on their desired next result (turn a faster lap to stay ahead of the others, get closer to the rider in front and set up for a pass, etc.)

Each lap is a sprint. One fast lap does not guarantee a race win.
Each race is a release. One race win doesn’t guarantee a championship win.

Consistency is key.

Vision, plans, execution, evaluation, tweaks, repetition, strategies, using them accordingly, focus, flow. Wait, am I describe racing or a scrum project?

Image source: Pixabay

Leave a comment

Time, Energy, and Focus Management

There are tons of books and resources about time management. Time is important; one can always make more money, but not more time. We all have the same 24 hours each day, so managing how we use our time is very important, indeed. However, time is not everything.

Even in the unlikely event of having a lot of time in our hands, what if we don’t have the energy to make anything with it? So, energy management is equally important. But time management and energy management are not everything.

We may have time, we may have energy, but what if we don’t have focus? Without focus, we’re likely to deplete our energy and waste our time.

If we have time, we can find ways to replenish energy and focus.

If we have focus, we can find ways to better use our time and and energy.

If we have energy… you got the idea!

Time, Energy, and Focus management. Finding the proper balance between those three points allows us to get more meaningful things done.

I have many posted related to how I try to find that balance under the productivity and lifestyle categories on my blog. Check it out!

Leave a comment

Virtual Brown Bag: October 2020 Summary

Another month full of Virtual Brown Bag meetings in the books and the variety of topics keeps increasing.

Check out what we’ve been up to in October and join us to participate in the conversations as well! Every Thursday, 12-1pm Central Time.

  1. October 29th, 2020

    We talked about Microsoft certifications, past and recent experiences. We also spent some time talking about custom matchers in Cypress.io, and security-related static analysis tools.

  2. October 22nd, 2020

    Great discussion remembering the Alt.NET movement, and also talking about architecture katas.

  3. October 15th, 2020

    Obs and PPT automation, Books (Righting Software, .NET Architecture), DDD, Event Storming, CQRS, REST… great conversation!

  4. October 8th, 2020

    Some more talk about Mmhmm, anti-fatigue mats, home-office setups, nerves-project.org, IoT, Elixir, micro-services and data for dashboards, AWS and AWS Amplify.

  5. October 1st, 2020

    Mmmhmm (virtual camera, setup, experiences), EICAR test string, Spam Pull Requests, things we put in the resumes, databases: when to start thinking and making decisions about them…

,

Leave a comment

Virtual Brown Bag: September 2020 Summary

September was another month with great Virtual Brown Bag meetings: large variety of topics and great conversations!

Join us every Thursday, 12-1pm Central Time.

  1. September 24th, 2020

    Cypress.io, Trust (the struggle is real… how to build trust?), OSS maintainers and leadership, Blazor.

  2. September 17th, 2020

    Xamarin, React, state management, data migration and source control, Surface Laptop, job interviews, DB natural IDs, managerreadme.com

  3. September 10th, 2020

    Mmhmm (making it for better virtual meetings), TypeScript, Swagger, Express.

  4. September 3rd, 2020

    Main smartphone apps we use, discussion on technical writing, top-level functions vs classes, Python.

,

Leave a comment