Category: Learning

Bob Pusateri describes a common promotion path:

But one piece of career growth that I’ve never gotten from any employer is a promotion.

Allow me to define “promotion”. In my mind, a promotion is where an employee earns a change in job title with commensurate increase in responsibility. I won’t even say it has to include an increase in pay, though I imagine it often would. Similarly, a promotion need not involve moving into a management position. Simply put, to me a promotion is doing a great job as a junior widget maker and then one day being told your hard work and contributions have been noticed and you are no longer junior.

This is pretty common. As an example of the other side of the coin, I’ve been promoted (using Bob’s definition) at two separate companies. But in a lot of cases, hierarchies in engineering teams have nearly disappeared, such that there’s no longer a Software Developer 1 who can be promoted into a Software Developer 2, and then a 3 and a 4, and then an Enterprise Architect 1, etc. Instead, out is the new up.

The funny part of the pattern is that I know people who have left a company in order to move up. Then, after some time with the new company, they return to the old company in a higher role.

Cathrine Wilhelmsen shares a tip for improving those presentation skills:

Did you know that PowerPoint can help you improve your presentation skills? 💡 If you rehearse with the PowerPoint Presenter Coach, you can get real-time feedback on things like your pace and language. If that’s too distracting (it is for me), you can choose to hide the real-time feedback and only view the detailed report at the end of your rehearsal.

The report shows you details about the total time spent, your pace and pitch over time, whether or not you are simply reading from your slides, as well as actionable feedback on your language. The feedback includes whether you are using too many filler words (like umm, actually, or you know), whether you are using too many repetitive words with alternatives you can use instead, whether you are using any words that can be offensive, and specific sentences that you can refine.

Click through for more details.

Julia Evans catalogs things to avoid when providing explanations:

This list isn’t meant to make you feel bad about your writing. I’ve probably done all of these things! I’m certainly going to do them again! I even did at least one of them while writing this post!

But knowing that I’m likely to accidentally do these things makes it easier for me to avoid them, and it makes me more receptive to critique when people point out issues with my writing (“Julia, this is assuming a lot of knowledge that I don’t have!“).

Being aware of these patterns also helps me when reading a confusing explanation: “oh, I’m not confused by this explanation because I’m stupid, I’m confused because it’s introduced 6 new-to-me concepts and it hasn’t explained what any of them is yet!“.

Read on for the list and some excellent explanations of what to do and what to avoid when trying to explain things clearly to people.

Kenneth Fisher airs some grievances:

Many years ago I was given a work request that literally just said:

It’s broke. Fix it.

I’m sure you can see how that is supremely unhelpful. And this isn’t the only time I’ve gotten such great requests.

Kenneth has some great advice here when framing requests and I have just one more thing to add: err on the side of using nouns over pronouns, even when it feels repetitive. “I was in the XYZ service and when I clicked the button, it stopped working” is a mess of an error report because it could refer to the service, to the button, or to some third thing which you have in mind but never wrote down.

Mark Seemann reasons through a difficult problem:

Perhaps we’re really talking past each other. Perhaps we’re trying to solve different problems, and thereby arrive at different solutions.

I can only guess at the kinds of problems that my heroes think of when they prefer dynamic languages, and I don’t want to misrepresent them. What I can do, however, is outline the kind of problem that I typically have in mind.

I’ve spent much of my career trying to balance sustainability with correctness. I consider correctness as a prerequisite for all code. As Gerald Weinberg implies, if a program doesn’t have to work, anything goes. Thus, sustainability is a major focus for me: how do we develop software that can sustain our organisation now and in the future? How do we structure and organise code so that future change is possible?

Reading Mark’s essay makes me want to break out my copy of Tractatus Logico-Philosophicus but let’s not go crazy here… This is a good reminder, however, that incentives (implicit as well as explicit), experiences, and a host of other factors which make it really difficult to say conclusively “X is a better solution than Y” without laying out the specific premises.

Erik Darling wraps up a slew of videos:

Over the last month, I’ve given away all my beginner SQL Server training content. I hope you’ve enjoyed it, and maybe even learned a thing or two.

After this, I’ll be getting back to my regular blogging.

There are a lot of videos to check out, and right now, Erik has a big discount off of his advanced training, so go, go, go.

Camila Henrique explains the importance of knowing SQL:

I wanted to talk about this because I see a lot of doubts and lack of direction from people who are either beginning now in IT land or thinking about switching careers. The short answer to “do I need to know SQL for a data job?” , is yes. In the next few paragraphs I explain why I think so.

It’s easy to get caught up in all the fancy programming languages and methodologies for projects that sometimes the basics… are just not there. I believe having a good foundation opens paths to other doors that you could not see before. And I’m certain that SQL is one hell of a foundation to have in the data land.

This is also a good time to slip in a reminder of Feasel’s Law.