Peter Schaafsma

Resharing this as endorsement - tech compensation is *at least* bimodal, and likely trimodal (depending on your location). This article is a great read for all engineers, to help explain the market and know their worth. I saw this firsthand in my job search last year. There were local companies in the Chicago area that capped out at ~120-160k for senior roles, and then larger firms (especially in finance and tech) that reached ~180-200k. But it wasn’t until I got into interviews with large public tech companies that I saw base salaries of 200k+ advertised, and total compensations reaching from 250k to 500k and up! Gergely Orosz's articles on this topic have been a huge help to me. If I had stuck to what I saw in the local market, I would've drastically limited my options and short-changed myself. The surge in remote work has made it more possible than ever to work for some of the best companies in the world, and even with lots of return-to-office happening, there are still plenty of great and well-paying companies out there. So if you're on the market (or thinking about it), keep this in mind! 🚀

6

Alright, it's a little behind schedule, but v4.15.0 of Nebula Logger is now available! This release brings several new features & bugfixes to the managed package (as well as few small enhancements to the unlocked package). Some of the highlights for anyone upgrading from v4.14.0 to v4.15.0: Key Features ✅ OmniStudio Logging: Built-in support to easily log from OmniStudio, a much-requested feature! ✅ Loosely-Coupled Dependencies: ISVs and consultants can now seamlessly leverage Nebula Logger without requiring it as a dependency. ✅ Enhanced JavaScript Logging: A new getLogger() function makes JavaScript logging even easier & provides improved support for logging in LWC lifecycle events Other Enhancements ℹ️ Dynamic highlights and related list components for flexipages, leveraging Salesforce's Winter '25 features. ℹ️ New list views and formula fields on logging objects, improving usability and visibility. ℹ️ Apex updates for better HttpRequest logging, async context handling, and more flexible LogEntryEventBuilder methods. ℹ️ Optimized internal performance and streamlined sf CLI commands to align with Salesforce’s latest standards. Bugfixes 🐞 Enhanced regular expressions for data masking sensitive info (e.g., SSNs). 🐞 Fixes to Apex context handling, long code snippets, and visibility rules on console tabs. More details are available in the release notes: https://lnkd.in/eBKVkfZr #Observability #Logging #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceArchitects #OpenSource #Apex #OmniStudio #ISV #LWC

77

4 commentaren

The word Medium......🤮 I can't use it. I cannot get it out of my mouth. At Itsavirus we use to work with naming our engineers like so many other companies do; junior, medior, senior, expert.... But the whole idea that we have "medior" people does not fit with my beliefs... at all. ➡️ First of all; people can never be 'medior'. We are all valuable in our own right. Calling people 'medior' sucks. ➡️ Secondly; I don't allow for any form of mediocracy in our company. It has no place at Itsavirus. We strive for the best. Any reference to 'medium' is just simply wrong. In my opinion engineers at Itsavirus are either skilled professionals that simply deliver or they are in the learning phase. And yes, also our skilled professionals keep on learning! This is one of the many reasons we have implemented IC levels. Below a rough description of how this works: 🐣 IC1 (Entry-Level): These team members are in the learning phase, focusing on growth and skill development. 🐥 IC2 (Proficient Professionals): Fully independent contributors who manage tasks autonomously, consistently delivering quality results. They provide reliable support and make substantial contributions to project outcomes. 🦆 IC3 (High Performers): Experienced professionals with a strong track record for excellence. These team members bring specialized knowledge, solve complex challenges, and deliver high-quality work and solutions. 🦢 IC4 (Leaders & Strategists): Our top-level experts who, in addition to providing exceptional work, also guide teams, offer strategic insight, and take on leadership roles to drive projects forward. The implementation of this model has more positive consequences 🛑 Junior Engineers No Longer Offered: Previously, having junior engineers in our offering made sense for handling simpler tasks. However, with the advancement of AI, many of these tasks can now be executed more efficiently using tools. 🛣️ Clear Career Path for Engineers: Our engineers have a well-defined growth path without the need to move into management roles unless they choose. This allows them to focus on their strengths and passion, building on technical expertise. 🫧 Transparent Growth and Fair Rewards: The IC model provides clarity on expectations and accomplishments, ensuring that career progression and compensation are transparent, fair, and aligned with performance and skills. 😎 Enhanced Client Experience: With defined IC levels, clients like you can have a clear understanding of the expertise and contributions each team member brings to your project. When we assign someone to your team, you know precisely what to expect based on their level. Added a picture to look tough ⬇️

44

3 commentaren

We’re getting close to typing some C#! We’ve described our components in plain language and listed their dependencies in the Architecture documents. At the very end of the stream, I talked a little bit about Contracts in software development, and why they’re important. We’ll talk about that some more this afternoon. The stream is archived in the usual place, I’ll link it in the comments. See y’all at 1:00 pm eastern over on Twitch! #thatDeveloperDad #liveCoding #softwareArchitecture #cSharp #dotNet 

1

1 commentaar

In 2021, I tried to understand how tech compensation really works - at least in the Netherlands. I published "the trimodal nature of software engineering salaries" article. Time for an update: Back then, based on ~100 data points (and my own experience as a hiring manager,) I suspected that there are three, distinctively different compensation bands for software engineers: 1. Local companies (Tier 1) Most local businesses that benchmark to the numbers on most salary comparison sites. They usually offer close to – and sometimes slightly above – what government positions advertise for senior engineering roles. 2. Ambitious local companies (Tier 2) Startups, scaleups, and more ambitious local companies that want to hire and retain the best people, locally. 3. Companies benchmarking across a region (Tier 3). Big Tech companies, hedge funds and scaleups that hire across regions, frequently hire from abroad, and often compete with fellow Big Tech giants for talent. Curiously, the third tier (Tier 3) seemed to be missing from most public compensation data sources. Since publishing the model, I've both received lots of feedback suggesting it applies to the US, Canada, UK, Europe and many other countries. I've since then also collected far more data points, manually tagged companies by tier, and can finally confirm that yes, this model holds up when compared with actual data. Here is the longer analysis (and the stats behind this graph below) in yesterday's The Pragmatic Engineer issue. Read it here: https://lnkd.in/e7FV4gBB

708

43 commentaren

My talk at #FrontendNation is available in full length on youtube. Let me know what you think.👇🏼 https://lnkd.in/e_GBNXTv I will post a link to an automation guide of my talk as comment. In this blog post you can also find the slides. ✅ #a11y #FrontendDevelopment #wcag #WebAccessibility

32

2 commentaren

As a freelancer in software development, it is easy to just hop from one assignment to the next. There are always nice projects to work on and normally there is more than enough work. But it is also nice to invest in yourself, doing a course or gaining experience by doing a (not directly paid) project, for example by creating a prototype. So when my previous assignment at Alfen ended, I decided to wait two months before starting the next assignment and start a project to create a prototype. Just to get more hands on experience in #C #embedded #software #development and #FreeRTOS. I created a nice project with a #Nordic board and some sensors. It is fully documented and available on Gitlab, might you be interested: https://lnkd.in/eJQfwAJi What do you do as a freelancer to keep yourself up to date? Just gain more work experience or do you also sometimes give yourself such a present as I did to take time to learn something new?

22

The skills required of web developers vary depending where you are in the world. Javascript is by far the leading skill required across all nations but .NET is as important in Belgium and the Netherlands. Want to see the breakdown in more detail, this chart can be found here https://lnkd.in/eeGZki57 #webdev #javascript #digitalskills #skills #lightcast

6

State management is a challenging software engineering topic. State creates dependencies, and dependencies create complexity. Therefore we need to understand how to manage state. I recently heard someone say that we should aim to remove all raw for loops from our C++ codebases and replace them with std algorithms. At first I didn’t grasp his point, but I soon began to realize that he was trying to explain that raw for loops expose state. We don’t want to expose state, instead we want to encapsulate and manage state. Managing state was the topic for my talk at the Audio Developer Conference ‘23. In this talk, I share my thoughts about it in the context of JUCE (a C++ audio software framework) applications. In audio software, we have to deal with different forms of state including global settings, presets, UI state, and application state. State must be stored and restored and must be synchronised throughout the app across different threads (at least the audio and main thread). State sometimes needs to be synchronised with other software, such as a DAW (Digital Audio Workstation). There is a lot of debate about how to solve all these problems, and I’ve seen a lot of people do this in different, some good and some bad, ways. How you do it matters. It all starts by knowing the JUCE framework and understanding the fundamental JUCE objects, including the AudioProcessorValueTreeState, ApplicationProperties, Value and Vars. Knowing these objects will help you to build up a state system that suits your application. You can watch my talk now on YouTube! Go ahead, watch it, and feel free to send me a message with any question or comments afterwards. #softwaredevelopment #juce #audio #c #plugins #statemanagement

20

Being in this profession for almost 28 years, I like to think I've seen the evolution that developers go through. In fact, I've experienced it firsthand and made my fair share of mistakes. I don't think terms like junior, medior, and senior make a lot of sense anymore, though. I've seen aspiring developers whose technical skills and breadth of knowledge far exceeded those of developers with 15+ years of experience. That’s why it’s so important not to judge a book by its cover. Nonetheless, experience is something to take into account when working with developers on your team.   In general, developers fresh out of school have a lot to learn. The gap between what they are trained for, and the reality of our profession is simply too big. They'll be introduced to many new techniques, so giving them overly strict guardrails isn't prudent. Even those who are self-educated need some guidance. Over time, you'll notice that they start to question those guardrails and offer suggestions that show they’re becoming more aware of the rationale behind them.   This is the point where you need to remove the guardrails to give them more room to explore and fail safely. This is also the fun period. You'll have great discussions about why certain patterns or principles make sense in particular scenarios—and when they don’t. Ironically, I've learned that developers with 15-20 years of experience are often the most dogmatic and the hardest to work with. And obviously, those with 25 years or more know exactly what they're doing, right… Or not? 🫣 #lessonslearned #consultancy #avivasolutions #carreerpath #softwareengineering

17

BDD is the only sustainable TDD I’ve ever done in my career. I've done a lot (LOT) of unit testing. Almost all of it falls into a couple of categories: - Figure out an implementation, then create a test afterwards - Or a variant: figure out the happy path, then unit test all the ways it could go bad - Discover a bug, fix it, write a test to pin it down for the future Which are all good! I love unit tests. It's just that I've most often seen them written after the code was built and guided by the implementation as opposed to guiding the implementation. But I've actually done BDD for extended times on real projects where our first move was to start by writing the tests first - and it is wonderful. You have a real sense of what needs to be done next - you're either staring at an empty step definition that needs to be written (i.e. a new test), a currently failing step you need to fix, or a bunch of green lights that will watch your back on a refactor.

6

2 commentaren

Curious to hear your thoughts on Blazor development! 🤔 I've been diving into Blazor for large and small-scale solutions and I'm genuinely impressed with its capabilities. The component-based architecture, seamless integration with .NET, and cross-platform support have been game-changers for me. I'm keen to know: - Have you had any experience with Blazor? - What are your thoughts on its performance and scalability? - Do you see Blazor playing a significant role in future web development? I believe Blazor has a lot to offer and I'm excited about its potential. If you've worked with Blazor or have insights to share, I'd love to hear from you! #Blazor #DotNet #WebDevelopment #YourThoughts

4

I often use analogies to explain things to clients. Like all models are wrong, but some are useful, I’ve been talking about concrete trucks lately. How is that useful? I work with companies (investments) on transforming their software delivery culture and sometimes it helps to take a different perspective. 𝗣𝗮𝗿𝘁 𝟮: "𝗧𝗵𝗲 𝗖𝗼𝗻𝗰𝗿𝗲𝘁𝗲 𝗧𝗿𝘂𝗰𝗸 𝗖𝗼𝗻𝘂𝗻𝗱𝗿𝘂𝗺: 𝗔 𝗖𝗮𝘂𝘁𝗶𝗼𝗻𝗮𝗿𝘆 𝗧𝗮𝗹𝗲 𝗳𝗼𝗿 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗶𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀 𝗶𝗻 𝗣𝗘” Investors not only want to satisfy the investment thesis, they are under immense pressure to do so, as quickly as possible. The best way to do this is to deliver more often and with higher quality, my specialty. We say in Agile: you have to go slow to go fast, and sometimes being able to go fast requires us to go slow 𝗳𝗶𝗿𝘀𝘁. - Breaking apart the monolith takes time - Implementing feature flagging properly takes time - Writing automated tests takes time Investors often ask about using more resources to speed things up. In my head there can be a conversation about 9 women, 1 baby, and 1 month. However, our concrete truck analogy can again be useful! It’s impossible to build a house where you have the roofers and the concrete truck to pour the foundation show up on the same day. But Dave, could we use more resources to speed things up? You could have 100 concrete trucks show up that day, and the roof will not be finished a second faster. When improving software delivery cultures, there are dependencies, just like in code. The best portco CTOs will use some of the techniques listed above (and more) to help break those dependencies (loose coupling) and to deliver with more speed and quality (I help them with this). The concrete truck analogy can help leaders at many levels understand the limits of resource constraints, but also, how to identify and manage the constraint, so CTOs and investors can deliver on the thesis. #privateequity #software

8

1 commentaar