Archive for category Software Development
One of the book clubs I’ve joined last year with my fellow Improvers was on “The Pragmatic Programmer – Your Journey to Mastery – 20th Anniversary Edition”. I remember reading the 1st edition sometime around 2006 and am glad I reviewed its newer edition.
Here are some notes wrote down…
“You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations.”
That! I have (bad) memories of wasting a lot of time because a particular tech stack was chose for no reason other than a marriage to a particular vendor, despite of it not offering the best technology to achieve the client’s goals.
“Care about your craft: there is no point in developing software unless you care about doing it well.”
I wouldn’t trust surgeons who don’t care about doing their craft well. Would you?
“Over the long term, your time investment will be rapid as you and your team become more efficient, write code that’s easier to maintain, and spend less time in meetings”
I love the point above. I enjoy doing code review with team members so we can learn from each other. I’ve worked on teams where at some point we couldn’t tell which one of us wrote the code, because we’ve learned to value the same best practices, which we kept in mind in our daily work. Whenever someone learned something new, they’d share with the team, and we’d evolve together.
“We who cut mere stones must always be enviosioning cathedrals”
YES! Developers shouldn’t be content with dropping a button onto a form that when clicked shows whatever message; they should see through it and understand the bigger context.
“If technology seems to be passing you by, make time (in your own time) to study new stuff that looks interesting. You’re investing in yourself, so doing it while you’re off-the-clock is only reasonable.”
That’s precisely what I’ve been doing for a very long time. The main difference is that I started to apply that not only to technology, but also to many other areas of life. What I’ve done off-the-clock has always been the biggest driving force behind my continous improvement.
“Above all, your team needs to be able to trust and rely on you – and you need to be comfortable relying on each of them as well. Trust in a team is absolutely essential for creativity and collaboration. In a healthy environment based in trust, you can safely speak your mind, present your ideas, and rely on your team members who can in turn rely on you. Without trust, well…“
If you ever visit Improving.com, you’ll immediately see the following words: “Trust Changes Everything”. As I look back on my professional career, I can point out several opportunities and growth that came out of being trusted by people from all walks of life. A team without trust isn’t much of a team.
Pushing that concept a little further, I like a point raised by the authors of “Yes, And: How Improvisation Reverses ’No, But’ Thinking and Improves Creativity and Collaboration — Lessons from The Second City” (another book club we had last year!) The point they raised is to go from team to ensemble, which is an even more collaborative relationship. In Improv, it’s very easy for one to become very uncomfortable, but a strong ensemble is there to support each other when ramping up skills or going through an off night.
“Don’t live with broken windows. Hopelessness can be contagious.“
That one makes me think of teams that abandon their automated tests because they have become brittle, hard to maintain, hard to write, hard to fix when they start to fail.
“Be a catalyst for change“
Nobody else writes tests? You should do it, regardless. Nobody else writes clean code? You do it! Nobody else says “thank you” anymore? You do it. Thank you.
There were many other great things in this book and I strongly recommend it to anyone who’s anywhere near software development. Most of the lessons taught have stood the test of time, and the ones that didn’t (due changes in technology and such) were revised and updated in this 20th Anniversary Edition.
Here’s the talk’s description:
Most developers hear about “Red->Green->Refactor” as part of the TDD process. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.
After a short hiatus, the Improving Code user group is back. The first talk of the year happens online next week, Feb 3, 6:30pm CDT. RSVP here, will ya?
Refactoring Test Code
Every developer hears about the TDD process as “Red->Green->Refactor”. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.
I have mentioned about the importance of technical communities for me. This month, I take a moment to reflect upon something I was doing related to communities 20 years ago: in January of 2001, the first issue of RapoZine was released!
Still living in Brazil at the time and participating in a community that craved for content in Portuguese for Visual FoxPro, I got together with two other members of the community to put out this little magazine. Leandro W. and I would each write half of the content, and Nilton P. would take care of the website where people could subscribe.
We’d print out the pages at whichever company we were working at the time, and mail it out to the subscribers. Simple and easy. Nothing fancy needed. The community was craving for content! For that first issue, we also enjoyed an article contributed by Ellen W., from CoDe Magazine.
In its first year, we had about 120+ subscribers.
It was a ton of work to get monthly content written and put out like that. That’s how I got started on technical writing.
The name RapoZine was a combination of “Raposa” (Fox in Portuguese) and “magazine”.
When the printing and mailing costs got too high, we eventually alternated into a digital version. The articles were created in HTML, compiled into a password-protected EXE file, and a download link was sent to the subscribers. I need to dig up some old backup files… I may still find some of those issues here.
With my plans to move to the US in 2002, I didn’t have time to keep the magazine running. Fortunately, the main worldwide FoxPro community at the time, the Universal Thread, which also had their own electronic magazine, UTMag, approached me to join forces, and we merged UTMag/RapoZine for the community. The magazine became free for all, and published in three languags: English, Portuguese, and Spanish! The Universal Thread had a great system to allow translators to collaborate and get the content out. I continued as a co-editor and coordinator for the translation team. About a year later, the Univeral Thread acquired RapoZine, and I stepped away to pursue other goals.
I enjoy having some music playing while I work; even more so if I’m using the Pomodoro Technique. But I’m very specific about my work soundtrack!
If what I’m doing the requires deep thinking, I need instrumental music. Most often, that’d be classical music (Mozart, Beethoven, Vivaldi, Bach, Chopin, Paganini, are among my favorite), but it may also be World Music (Kitaro is my top favorite). For shallow thinking, I may go with guitar albums by Joe Satriani, Steve Vai, Steve Morse or maybe movie soundtracks.
When I already know what needs to be done (either because I’ve finished the deep thinking mentioned above or because the task is just busy-work), then I crave some high-energy music (usually heavy metal, but it could be some other things I have in my music library).
Here’s an example:
I’m about to implement a user story. I set two Pomodoro sessions: one session to read through the user story and acceptance criteria, review mockups, etc, and another session to write my specs for it (only the Given-When-Then statements). My soundtrack consists of classical music.
Now I’m ready to write the actual tests and just enough code to make them pass. The soundtrack may be some fierce heavy metal, as I blast keystrokes on the keyboard. As I do this, I may practice the “sing and read” speed reading techinique; as I sing my favorite songs, I read through my tests, write code, read what I wrote, and eventually read it again in preparation for some refactoring.
Do you have a soundtrack?
Challenge times bring us the opportunity to either reinvent ourselves or flex muscles that had been dormant. I’ve talked about the importance of technical communities in my life, how they help us improve our networking skills, how we can use our voice and reach out to others.
The year of 2020 has made us all push the envelope when working with our communities, either creating new ones or keeping existing one engaging to their members. While many of us miss the in-person communities, we have also been learning how to make the best out of online communities.
Tomorrow, Dec 18, I’ll be on a live virtual Lunch and Learn with my good friend, talking about our experiences Building Stronger Online Communities. Join us at 12pm Central Time! Click here to find more information about this FREE event and register.
This is the session description:
User groups are a great way for the community to get together to share, learn and network around specific common interests. This year saw us having to pivot to virtual-only events and uncovering both opportunities and challenges… How can we create great community experiences in a virtual world? In this Lunch and Learn, attendees will hear from two community leaders, Sarah Kim and Claudio Lassala, on how they’ve been growing their online communities and hosting virtual events.
Just a couple of weeks ago, I’ve blogged about The Importance of Technical Communities (the ideas really apply to any community in general, much like what I do with my motorcycle track riding community). In this post, I’ll focus on the networking side of getting involved with communities.
Every week, I share things on the Virtual Brown Bag; I may share an article or book I’ve read, a challenge I’m facing at work, a successful way I’ve found to implement something. Whatever the case might be, once I’ve shared it with the community, I’ve planted a seed in their minds: should they either run into the same challenges or solutions to it, they’ll think of me. They’ll know who to either ask questions or offer help to, or make connections (“Hey, Claudio, last week you mentioned you were having issues with Cypress. I mentioned it to a co-worker and he has the solution. He’ll be reaching out to you!”).
I’ve talked about similar things when I shared my thoughts on “fake until you make/become it”. We don’t need to figure it all out by ourselves. We don’t need to fake it. Others will help, but we need to either ask for their help or let them know that they could possibly help us.
Every month, I update my “Now page”; that’s an easy way for people to know what I’m up to. A few months ago, I mentioned I was starting to work with Angular. Less than half an hour after I’ve posted it, an old co-worker who I hadn’t talked to for a few years reached out to say he’s done a lot of work with Angular and I should keep him in mind if I had any questions. We also took the chance to catch up with life in general.
Last week, I’ve read Derek Sivers’ writing on how you can take a situation that may not be ideal and flip it in your favor. He touches on “it’s all who you know”, and got me thinking about how my professional career started; I walked to my whiteboard and sketched out my career map up to today, calling out every single person somehow responsible to pivotal moments. How did I meet them? How have they helped? Have I been keeping in touch with them? Have I expressed my gratitude to them?
A good book I’ve read on the subjet of networking is The Power of Who.
Our communities and networks can (and should) be connected. People in my technical communities are aware of my involvement with motorcycle track riders; those riders are aware of my involvement with software development. They are all aware of my activities as a musician. These are all opportunities to connect with people, expand my network, offer help, get help, improve, grow.
Front-End development technologies come and go. In my experience, they have been the single most volatile part of software. Their lifespan seems to be very short (5-10 years).
Why are they so volatile?
- Probably because the devices the users interact with evolve far faster than what they don’t interact with (back-end, databases and such);
- Users now expect more. Back in the day, users would happily use whatever software they had to automate their work. That has changed over the years as most people have their own personal computers and devices, which they use for way more things than just “boring accounting and payroll systems”. Also, since the first iPhone came out, users have learned to expect software to be more intuitive. And now “there’s an app for everything”, and for each app, there are likely multiple options to choose from.
Since the late ’90s, I’ve worked on a huge number of software “rewrites”. Most of them were really painful and time-consuming. Why so?
- Developers put way too much code on the front-end;
- In most “rewrites”, people simply want to replace the old with the new, making the new one look and behave like the old one, but on a different platform
Every time a new front-end toy comes out, I’m mostly interested in seeing how developers are writing code in it. More often than not, I see the same pattern over and over: a TON of code put right there in the front-end. Knowing that these frameworks and libraries aren’t like to last more than 5-10 years (by last I mean to be continuous developed), I know that a rewrite for such software means, well, rewriting all of that code!!
For the most part, the front-end part of software should simply allow the user to ask questions to the system and see responses. That’s it. Present the users with what they need to formulate questions, and then show them the answers in the best way possible (which could mean, fast, or illustrated with charts, or whatever it takes to give users the insight they need in that moment of time). In certain scenarios, it may be crytical to have most of the processing happening on the front-end, but those are the exception, not the rule.
Don’t get me wrong: I used to jump at every new shiny toy, too. There was a time when Microsoft put out a new toy called LightSwitch. That was probably the first time I looked at a new toy and thought “hmm, I don’t think that thing will last long”.
I didn’t quite recall when it went away, but found out on a quick search that its lifecycle started on Oct 30, 2011, and it’s mainstream support ended on Jan 1, 2017. The official death announcement states that “the landscape has changed significantly from the time when we first thought about LightSwitch”.
Such a shame. I had worked so hard on adding LightSwitch to my resume. I had even documented my proficiency with it on this short 45-second video!
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…” 😉
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…