Forem: John Zittlau

Goals Hurt

John Zittlau — Wed, 09 Aug 2023 17:05:32 +0000

I was recently listening to a podcast where the speaker was someone being introduced as very successful. By many metrics they were. They had lots of money, C-level at a respected company, had competed in world cups and been nationally ranked in a number of diverse sports. Yes, they had accomplished lots. As they were sharing their thoughts on how to succeed, one of their primary thesis was to set big audacious personal goals. Don't set a goal of being worth 1 Million, set a goal of personally being worth 100 Million (or maybe even a billion). The reason for a very hard goal (they said) is that if you set an easier personal goal, then when you achieve it you'll be lost. Cast adrift. Have nothing to work for. You'll have to spend time finding a new goal and you may find that you've "wasted" your time on your old goal as it doesn't lead directly to the new one.

I could not relate to this way of thinking. I have no problem finding valuable things to do without audacious goals and by many measures I view myself as successful. Further, I do not believe that formally setting goals has contributed to my success. In fact, as you read further, you'll see that I believe formal goal setting to be more of a hindrance than a benefit for me.

We're constantly hearing from "successful" people that they owe their success in large part to setting goals. That the goals gave them the drive to persevere. To push through obstacles and make those goals a reality. I'm sure they believe that. I'm not sure it is a universal constant. Or that it is the one-true-way to success.

The belief that setting personal goals leads to success is so pervasive that it has taken on the status of a law of nature. Set big goals. Drive to achieve them. Profit. Many companies see personal goal setting as a critical part of career development and the road to producing high-performing individuals. Everyone is tasked with creating goals for themselves and then measured on how well they achieve those goals.

This is such a universal belief that it is only now, after almost three decades of professional life, that I've finally developed the confidence and courage to say that goals don't work for me. For most of my career, I've figured something must be wrong with me. Everyone says set goals and win. I set goals and could care less about them. The presence of a goal does almost nothing to push me along. And if I have been forced to set a big goal and don't achieve it, I feel demotivated. But not demotivated in a way that makes me want to try and achieve my next goal. Demotivated in a way that makes me want to simply give up.

Let's be clear on one thing here. I'm talking about personal goals. And also mostly the bigger goals (anything with a timespan larger than a month). I do set small goals, but not as a "forcing function", but rather as a prioritization tool. I also see team goals differently. Setting reasonable goals for a team is valuable. It helps ensure the team is moving in the same direction. It likely is helping team's prioritize, much as small personal goals help me.

As I've said, I do set little goals for the day or weekend or maybe week (a month on the extreme outside). That does help me prioritize what to do, but it doesn't drive me to do anything. And if I don't achieve my daily goal, I'm OK with that. As long as I'm happy with how I spent my time, then I'm good. Maybe that is the one goal that works for me. Be sure I'm happy with where I put my energies for that period of time. At work, this means I'm happy when I'm confident that what I did helped Jobber and was among the most important things I could be doing at that time.

On the weekend, being happy with how I spent my time could mean that I'm happy I spent a bunch of hours in front of the TV or video game. Or maybe I'm happy having done some woodworking project. Or I created an awesome Sunday meal. Or maybe I did spend the weekend diving into some new learning that will help my career. Clearly, I'm not a driven person. The journey is at least as important as the destination.

I remember the first time I worked somewhere that asked me to set career goals. I'd never done it before and was happy with where I was in my career, but set the goal anyway. Then a year later I hadn't achieved the goals I'd set. Boy did I not like that. But as I said above, it didn't motivate me to change anything. It just made me question if I wanted to stay at the company that was forcing me to set goals. It was already clear to me then that setting goals was not helping me achieve in any way and in fact was just making me less happy with life.

I suspect we hear about this path to success a disproportionate amount of time. It seems far less motivational to hear from those who "just fell into something". That doesn't provide for any life hacks to take. Setting goals is something anyone can do. Getting lucky isn't. So we hear from those who have a "solution" we all can do. The simple advice to riches draws attention. It promises a quick fix. Who doesn't want a quick fix that will put them on magazine covers.

I believe now that in many cases those who credit setting goals as the driver to their success succeeded not because they set goals, but that they have a "goal driven" personality. They are ready to put everything else aside to "succeed". Setting goals isn't changing their approach to life. Their approach to life includes setting goals.

There are others, like me, who are happy to let life take us where it will. Where setting goals is contradictory to what wakes us up in the morning. Where defining a goal is hard and caring about that goal is even harder. For us, when the company says "create goals" we grumble and do it because we have to, but we don't like it. And it doesn't help us to succeed. If anything, when we review the goals, we're irritated and stressed that they are there and want to find a safe place where we can grow without having decided how we will grow in advance.

I'm now a Distinguished Software Engineer. I think I can point to that as evidence that I've "succeeded" as a developer. Can I credit goal setting for getting here? Absolutely not. In fact I had to fight through hating the goal setting process to continue on as a developer. The temptation to find someplace safe without goals has always been strong.

You may have noticed that I put "succeed" in quotes everywhere. That is because in too many cases when I see someone has "succeeded", it is in one facet of their life at the expense of some other. Even I did that above where I tied my title to being a signifier of success. Often money/career is viewed as success. Family/friends don't even enter the conversation.

I confidently say I've succeeded without the quotes. I may not have Elon Musk levels of money, but I get by. I may not have huge followers on some social network, but I have solid friends. And I have a solid family. Everything in balance. I'm happy. At least until the next time I'm asked to set a personal goal.

So who's with me? Are goals essential for success? Do they help or hinder you?

About Jobber

Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!

Me Style, not Committee Style

John Zittlau — Mon, 11 Jul 2022 16:52:56 +0000

(Note: This post describes my opinions on the matter, not Jobber's. At Jobber we have a healthy style guide and a dedicated group tasked with keeping it current and relevant.)

It started with K&R vs. Allman. Where do the braces go?

K&R

if(true) {
  do something
}

Allman

if (true)
{
  do something
}

(And many more variants existed then and now.)

Many a holy war was held over this.

Then we started defining more rules for how the code should look. Thus begat the code style guide.

It would talk about braces, and spacing and probably variable names and a number of other things.

Now we had a half-page of things to disagree about. And many a holy war was held.

Eventually, the stylesheet grew to a page or more.

Now we couldn't remember what we disagreed about. Thus begat the linter.

If we can't remember the rules, let's put them in a program and electro-shock developers when they misbehave. And now the computer itself was waging the holy war against developers.

Since we don't need to remember all the rules in our heads, we can create more rules. The electroshocks became a constant buzz. Lights dimmed.

This would not do. Think of the climate. Thus begat the prettier.

Now developers could type whatever the heck they wanted. Once they were done, the computer overwatch would "fix" the code to comply with the style bible.

And so the holy wars ended. Our computer overlords had won.

The above is only kinda tongue in cheek. I feel our current obsession with extreme style guides is misguided. I don't think we achieve a great deal by ensuring every developer's code on a project looks like every other developers.

The reason is almost always given as "faster readability". But really, if there is a blank line at the end of a file, will anyone care?

Sure there are outliers. We need some amount of consistency. But I contend that if we could somehow put a number to a coder's style, and then plot those numbers on a bell curve, anything within 1 standard deviation will be easily readable by everyone on the team.

Some current style "darlings" that may well be harmful.

Line Length
What should a maximum length be? 80, 100, 120, 1000?

I've heard people still stick to 80 because they believe that is close to the 60 that most books limit to. They point to studies showing that reading comprehension is best for lines around this length.

Well, I don't know about you, but when I'm looking at code. I'm scanning most of the code to find the place I need to pay attention to, and then I'm reading for deep comprehension. And guess what? Studies also show that long line lengths are better for scanning.

So do we optimize for the case of deep understanding that we do for a smaller subset of the code, or do we optimize for quicker scanning so we can get to the right place faster.

I don't know, but I sure do know that there is not a simple answer.

My preference. 100-120. We all have big monitors these days. Any shorter line length and we seriously detract from the vertical capacity of what we can see. And I know vertical space is precious to me. I put a lot of value in seeing more of the shape of the code vertically. Although there is a happy bound here also. I find having a monitor vertical gives me too much vertical context.

This suggests line length may well be a very subjective thing, and also that in a perfect world, we could easily change the line length for different tasks. We might be close to that. Prettier's aren't bad at shortening a line. Maybe we simply allow them to also lengthen lines when appropriate. Then we can move back and forth between optimals. (But I'd want the saved file to keep the choices the developer made rather than what the prettier has currently done.)

Braces
OK. For me, there is One True Brace Style. And that is K&R. But really, is it going to slow down a dev's reading comprehension if the brace is on the same line versus the next line. I don't buy it. I'm not even convinced it needs to be consistent in a given source file. But maybe I'm superstitious enough to not want to tilt at this windmill too hard. Keep it consistent.

Oh, and NEVER SKIP THE BRACES.

If most code does

if(true) {
  do thing 1
  do thing 2
}

and then if there is only a thing 1,

if(true)
  do thing 1

with no braces, you are just asking for a bug when someone comes along adding a thing 2 without noticing the braces were not there.

Whitespace
I think white space isa critical part of a developer's
ability to communicate
intent
      . Just
             like
                paragraphs
    are an important part of
organizing prose.

Sure, as always, things can be taken too far. (See my value of vertical whitespace). But don't enforce where vertical spacing is allowed/disallowed. Trust the craftsman.

Method Length
I hate it when I see a developer creating a method to extract some code just to bring the line length of a parent method down to some prescribed limit.

Again, there are outliers, and I'll certainly agree that shorter methods are easier to read. But it seems like current recommendations for method length are taking that argument to absurdum.

Sure, many methods can be reduced to 15 lines, but not all. Again, when I'm reading unfamiliar code, having to jump to another method just to confirm that what the method implies it will do by its name is really what it is doing is a disrupter not an enhancer. There are certainly times when code should be extracted to capture a specific intent that isn't really a part of the parent’s primary intent, but extracting code just to shorten a method isn't helpful and is sometimes the only way to get past an aggressive method limit.

We should be trusting the developer. If the code is more readable by extracting some, trust that they will. Or comment on it in a review. Don't make a hard, inflexible one-size-fits-all rule for this.

Trust the Craftsman
In the end, I suspect many of these rules have been brought in as we bring lots of new developers into the herd compared to the seniors. New developers have less of a sense of what makes code readable and maintainable. The way developers are trained doesn't usually include much reading of code any older than a few weeks ago. Or that others wrote. But solve this with mentoring, not lawyering.

I firmly believe that developers are craftspeople. In woodworking, fine furniture done by a craftsperson often has a distinctive signature. You'll know who likely did something (even a century later), or at least who they admired and modeled.

Furniture that looks exactly like every other piece is made in a factory. Nowhere near as valued.

I know this is pushing an analogy to an extreme, but do we really want our developers to be producing factory code? Is that a good thing? Sure, no one but another developer will see the "beauty" of their hand, but as we diminish the freedom of a developer to create what they consider beautiful code, I think we also diminish their ability to solve problems in a beautiful way. If they are forced to write factory code, will their mind be limited to factory solutions?

About Jobber
We're hiring for remote positions across Canada at all software engineering levels!
Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.
If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!

Self healing code

John Zittlau — Tue, 19 Apr 2022 17:33:08 +0000

Yup, a grandiose title, but something to think about and try for when it makes sense.

What I mean by "self-healing code" is writing code such that when a problem happens the code automatically reacts in such a way that the current user is unaware of the problem and future users do not trigger the problem.

A pretty common pattern that does this something like this is the Circuit Breaker, although I suggest taking it further. The circuit breaker simply returns an error once it trips. Self-healing code ideally does something more helpful to the user.

Let's say you are writing code to find an optimal route between two points. You have a trivial solution that you wrote, but then find the super-duper-always-perfect route as an API online. Now suppose that API can be unstable and not always return a result, especially under load.

A self-healing solution could be to fall back to your trivial solution when you detect a failure. In addition, your application could remember that the super-duper solution is having problems and maybe not send requests its way until a cooldown period has passed.

Your customers still get a route. Maybe not the best route, but some route is likely better than no route. Additionally, except for the first failed call, remaining calls don't waste time going to a broken API and so the response to your customer is faster. Finally, the super-duper solution is given a break to recover. Eventually you start calling the super-duper solution again and all is good. This is basically the concept of Graceful Degradation. Graceful degradation fits into what I'm thinking, but what if there are scenarios where you can return the exact results back to the user after an error rather than maybe not the best route as above? This is the ultimate dream of self-healing code.

Here is another example that I actually went through that doesn't fit the Circuit Breaker pattern and goes further than Graceful Degradation. This led to my thinking on self-healing code.

Since HTTP GET requests should only be doing reads from the database, we figured we could easily distribute traffic between our primary database and our read-replica database by automatically sending DB reads from GET requests to the read-replica.

The problem. We discovered that we were actually writing to the database in our GET requests. Not all of them, but enough to make it an issue. We decided to fix the GET requests to do the right thing so we could go forward with this plan.

The problem. There were enough GETs that wrote to the DB to make it too large of an effort to fix them all. The benefits of the project wouldn’t balance the costs.

The insight. We could keep a "skip list" of GET routes that do a write to the DB. Then, we could automatically send GET requests to the read-replica database unless they are in the skip list.

The problem. Again, we have many GETs that write to the database and no easy search patterns that would assure us that we could identify them all in our codebase.

The self-healing insight: We can default to sending all GET requests to the read-replica database. If a write happens within the processing of that request, it will error out since it can't write to the read-only replica database. Then, we can detect that error and re-run the full request against the primary database. The user will be oblivious to the problem except for a slightly longer response time. The self-healing part is that along with re-running the request, we record this route into the skip-list. Now at most one user (roughly, threading complexities aside) will see a delayed response. All other users will automatically just go to the primary database because the route is on the skip-list.

The extra win. This becomes a comprehensive list of routes that need fixing. As we fix the routes, we can remove them from the skip-list.

This allowed us to immediately start seeing benefits from our work to move traffic to the read-replica database. We can focus on the most common requests that will have the biggest lift, and requests that are so rare they are maybe used a handful of times a day can be deprioritized. We'll fix it eventually because writing to the database on a GET is just wrong, but we don't have to fix every single bad call before our database can breathe a sigh-of-relief.

In the end, this was a big win, and this way of thinking can likely be applied in many other places. The concept of letting the code both gracefully detect an error and find another way of solving the problem is huge. Coupling this with the code remembering the error so it doesn't keep trying takes it to the next level. This can be leveraged in all sorts of refactoring attempts, particularly complicated cross-cutting concerns. Keep this in your back pocket! Any time you can simplify a big-bang solution to small bites, it is almost always worth the effort to do so.

Mentoring

John Zittlau — Tue, 01 Feb 2022 17:03:20 +0000

I've been mentoring others formally and informally for over two decades now. Below you'll see my thoughts on why I do it and tips I feel are valuable for both the mentor and the mentee in order to have a successful experience. You can hear some more of my thoughts on the linked episode of Culture of Code

Why I Mentor

The short simple answer is to give back. Beyond that is joy I get in seeing those I've mentored move on and succeed. Knowing that I've made a positive difference in someone's life is a big win.

I've had short term relationships with my mentees that have lasted a few months to long term relationships spanning more than a decade. I've met up with former mentees further down in their career. It is always rewarding to see how they have changed and grown.

Finally, I learn from being a mentor. Whether I'm doing technical mentorship or more general life and career type coaching, there are always interesting, new and hard questions that the mentees has. Digging in so that I can provide meaningful help is likely to lead to my growth as well as theirs.

How to be a successful Mentor

First and foremost, be a mentee. Seek out others to help you grow. Understanding the relationship from both sides is critical.

Second. Be humble and vulnerable. I've found that the best mentor/mentee relationships are those where the mentor is not afraid to say "I don't know" and also to share tough lessons from their past. By showing that you also are on a learning journey, you gain the trust of the mentee and are likely to have deeper conversations which can lead to deeper learning. This may sound less relevant to a technical relationship, but it isn't. The strongest thing you can teach anyone is how to learn for themselves. Role modeling that you are still learning is a powerful lesson.

Third. Meet your commitments. During a session, you may well commit to finding the answer to something or thinking further about an issue so that you can provide deeper insights. Make sure you follow up on those. If you don't, you are signaling to your mentee that you do not consider this time well spent. And if that is the case, you are wasting both people's time.

Fourth. Listen. Sounds obvious, but many of us get into the trap of planning what we'll say next in a conversation. Don't do that. You'll miss important cues. And sometimes the mentee doesn't know what they don't know and so understanding what they actually need help with can come from cues beyond what they say.

How to be a successful Mentee

First: Be there to learn, not to be shown the solution. The goal of having a mentor is to grow. You grow by learning and trying and sometimes failing. Just being given the lines of code to write or the paragraph to say will limit your learning. Expect your mentor to point you to a destination, but maybe not the waypoints on the way.

Second: Be humble and vulnerable. Just like for the mentor, you need to go into this being humble and vulnerable. Don't hide areas you know you need to grow in. Be your real self. If you are hiding your skill level, comfort level, mistakes you've made in the past, you are limiting how your mentor can help you grow. Why do that? And pay attention if the mentor wants to focus elsewhere from where you want. They may see something important for you to grow in.

Third: Meet your commitments. Again, just like for the mentor, although likely more so, you will leave a session with homework. Do it. If not, you are showing you do not believe this mentor/mentee relationship is important to you. Remember, the mentor is volunteering their valuable time. Respect it.

Fourth: Don't be afraid to ask someone you respect to mentor you. Many people are thrilled with the opportunity to help others grow through sharing their insights and experiences. They may be willing to just have a one-time coffee with you, or will happily plan for a longer term mentoring relationship. The worst thing that can happen when you ask someone to mentor you is that you've given them a strong compliment.

How to have a successful mentor/mentee relationship

Most importantly, set expectations right away. Here are some questions to answer:

Is this a one-time coffee, or a long term commitment?

Is this a technical mentorship or more a general career/personal growth mentorship?

Agree to the frequency of get togethers?

Agree to the initial focus.

Revisit the above regularly

Other things to make clear early in the relationship

Confidentiality. It is almost always the case that these meetings should remain between the two of you, but it can be acceptable in the case where the mentor knows your manager that some topics can be shared with the manager. Be clear on the boundaries here.

When will this end? Sometimes there is no clear end state, but in other cases, the relationship can be bound by time or achieving some goal.

About Jobber

We're hiring for remote positions across Canada at all software engineering levels!

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!

The Twelve days of Coding Christmas

John Zittlau — Mon, 20 Dec 2021 17:40:04 +0000

On the twelve days of Christmas, my true language gave to me...

I've coded in many languages over more than three decades (but this list doesn't really go back more than say two of those decades). Here is a list of the 12 features I remember being most happy to see (in no particular order).

1) Generics in Java
Yes, Java did not invent the concept of generics, but Java is where I was introduced to them. The ability to "strongly type" something and yet have that strong type not be hard-coded in the definition was revolutionary to me.

I'm a big fan of typing, and this opened up big flexibility while still maintaining typing assurances.

2) Swing UI
So I started using Java because it was an easier path for me to do some dot-by-dot rendering on the screen vs. MFC (which had a cost at the time).

This was before Swing and doing any sort of UI without events or the full palette of components that Swing brought to the table was a pain.

I'd used other UI systems (Open Look) that had much of this, but I couldn't wait to use a powerful UI "framework" in my chosen language.

Swing came along and made me look like a designer! (OK not really, but at least I could add buttons and lists and checkboxes oh my!)

3) Thread synchronization
Threads are scary. Rolling your own threading primitives to coordinate and sequence threads was common. When libraries started coming out that provided simple access to thread locks and thread-safe mutations, threading became a whole lot less scary.

There was a dark side to this. In Java (for example, and sorry for all the Java references, it wasn't the first language I used professionally, but it is still the language I've used most in a professional setting despite not touching it for many years now), threading became "too easy". What I mean but that is with all the constructs the language provided, it looked like threading was a "simple" thing to do. And so many developers who didn't have any business doing threads because they really didn't understand the dark sides of thread safety did threads. Much bad code resulted.

4) ORM
Hey, get off my lawn! I expect many of you reading this never had to deal with an application where you had to write every SQL statement by hand and then write code to copy the results of a query into some data structure that represents that data. (And then doing the reverse, manually building up an update/insert from that data structure)

ORMs (Object Relational Mappings) simplified all that. Now the heavy lifting of converting to/from SQL to your program's data structures is done magically and behind the scenes. So Easy!

And again, there is a dark side. Because the developers are removed from the SQL, they have far less insight into what is being done to the database, and bad DB performance is often the result.

5) Abstract Classes
I liked interfaces. They made sense and seemed powerful. I liked inheritance (even multiple inheritance). But what I really liked was Abstract Classes.

The ability to create a "stub" class that implements common functionality but leaves room (in fact requires) child classes to fill in the blanks. This opened so many doors in OO design for me.

Of course the kids these days, they'd point to mixins. And they'd be right.

6) REPL
This was (and is) a huge win. The ability to try some code snippet trivially without having to put that code in some "real" program and run the whole program is a huge time saver.

7) Online regex testers
It seems regex crops its head into nearly every project. I love regular expressions, but have to admit that I used to do lots of experimentation where I'd put some regular expression in the real code, then run it, dump the output and see what happens.

With online regex testers, you can easily play with your regex. And with the more powerful online testers, you can use multiple example lines to test many cases at once. Plus seeing how the groups are shaking out and everything. Big Win!

8) Frameworks that handle input sanitation and output encoding
Security is hard. Remembering to clean your input and output is hard. Modern frameworks that just do that for you are great. One less thing a developer needs to stress about.

Except not. developers always need to think through the security of what they are doing, so as with ORM above, these frameworks can provide a false sense of security (pun intended).

9) log file aggregators and search tools
Back in server-side pre-history, a server was a single computer. Maybe you had to combine a couple of log files all stored in /var/log, but it was all in one place and you could cat/sort/grep everything together and understand how things happened.

Then log files started getting organized in their own directories and piecing things together became hard. Then you had pool of servers and piecing things together became something you'd pay hard money for.

I can't imagine keeping a modern SaaS application live without these.

10) stream processing
I love being able to take a collection of items and then process over them stitching things together with Select/Reject/Map/Reduce and come out the other end with either a subset of the collection or an aggregate function of the collection.

Sure in some sense this is syntactic sugar to explicit looping (until you run in an environment where these commands work across multiple processing units), but done right, the intent of what you are doing is clear compared to what would happen in a for-loop and since you are writing a bit less code, you are likely to introduce fewer bugs.

11) Javadoc
Not sure Java was the first place for this, but it was the first I was exposed to. Being able to do some simple "markup" in the code and then have our API automatically documented in a nice searchable/indexable way was huge.

As with most developers, I'm not big on writing documentation. This took the effort to a minimum and made it less of a chore.

12) 12.days
Here's a Ruby one. Particularly when testing something time-based in a REPL (see below), I want to try different time intervals. In the past, I was used to doing lots of integer multiplication to get to seconds since the epoch from some number of hours/days/years in the past/future.

Ruby letting me just say "12.days" and have a meaningful Duration object is a huge time/brain saver.

13) (Special mention) Microsoft LINQ
This one gets special mention because I just don't have many opportunities to write code in a Microsoft environment and so have only had small chance to play with LINQ. The concept is awesome and I'd love to get serious with it.

There you have it.
The 12 (well 13) things I remember being excited of when I read about them. I'm sure there are many more I've forgotten and many I've just never been exposed to.

What about you? What language features could you not wait to try out when you heard of them?

About Jobber

We're hiring for remote positions across Canada at all software engineering levels!

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!

Header image used under Creative Commons Attribution-Share Alike 3.0 Unported and sourced from wikimedia