Gregory Witek

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

A few weeks ago I had a chat about engineering strategy. It sounds cool and is not like daily work, so interesting too. But it’s like the Yeti: we all talk about it but very few actually saw one. Why should you write an engineering strategy? Usually, you shouldn’t. If the company (team, department, whatever you have) is stable and works well, it’s a bit of a waste of time. You would just describe what to you already know. (It may actually be a good exercise: take a few design documents or documented technical decisions you’ve had in the past year and see the common principles: that’s your engineering strategy.) This tells you when you should do it: when something needs to change. The strategy is the description of what and how. Change often comes from a challenge your business faces: not enough customers, not enough revenue, or just getting wherever you want to go too slowly. (You may need a new engineering strategy because something changed in the engineering organization: a vendor goes out of business. You hire a lot of people and things cannot work the same way any more. ) Many times it’s a few of these problems at the same time. Your engineering strategy does not live in a vacuum: engineers are there to get specific outcomes for your product, your customers and your business. Most often it should work like this: Business strategy -> product strategy -> engineering strategy For a strategy to make a difference it has to do three things:  - recognize and describe the problem - make choices and describe an approach - lists coherent actions Here is a trap: these things being sold as strategy too and they sometimes sound good: - Goals as strategy (“we will be the leading...”, or “live harder” and of course “do what you love”) - Generic strategies (“we will win by being better” - thanks Sherlock) - Fluff / BS (“leveraging synergies” 🤡 ) Ok, back to the three things: 1. Recognize and describe the problem This is hard, especially in cultures that avoid mentioning problems as they are thought to be personal failures. 2. Make choices and describe an approach This is where you do most of the work. Figuring out what will solve the problem is where your responsibility as a leader lies. Making a choice is the crucial point here. You can’t choose everything (where would you put it all? 😀 ). A good way to test if your choice is real is to ask if the opposite would also make sense. So “we will get better” is not a choice, while “we don’t let teams choose the technologies they use” or “we don’t use the latest technology” are. 3. Coherent actions These are the things you will do, guided by your choices. This one has a test too: it has to answer the question “How”, 3-4 times. (Think of it as the adult version of “why”) Did you decide on doing something new? How do you get started? Do you need to transition things? How do you do it? What are the consequences? How do you deal with them? And here's Linkedin's word limit. Should I go on?

11

What happens when you ignore psychological safety and fail to keep up-to-date with tech debt in your engineering team? A lot of Shipping Stupid, as I learned the hard way while working at VeriSign, where a minor oversight led to a major DDoS attack. The lesson? Create an environment that encourages questioning and problem-solving without fear of reprisal. Prioritize tech debt, bugs, and test strategies. Embrace a zero-bug-tolerance approach. And be relentless in maintaining quality, even in the face of change. It's not just about avoiding 'Shipping Stupid', it's about fostering a culture of continuous learning and improvement. What’s your take on this? Let’s discuss. Follow me for more insights. #EngineeringManagement #TechDebt #QualityAssurance #SoftwareEngineering ----------------------------------- Check out the full article at https://lnkd.in/gY4wy75J

6

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

Have you ever heard of the golden cage phenomenon? For me, first thing that pops into mind is tech salaries. To explain this let's talk about how it in my opinion relates to compensation tiers in the Netherlands. First let's pull up a great blog by the Gergely Orosz: https://lnkd.in/enaUkC6S. It's worth a full read if you're interested in learning more about tech compensation in the Netherlands. I'll give my short summary here. The blog describes the trimodal nature of tech salaries in the Netherlands. In short, companies active in Netherlands can be put into one of three tiers of compensation for tech: Local Champions (Albert Heijn, Coolblue), Global Players (Adyen, Miro, Nike), and Big Tech (Uber, Booking, Amazon, Netflix). For more examples, check out the blog. Compensation can be wildly different between tiers, where second tier compensation can be 2x of that given in tier 1 and tier 3 can go up to 5x. In my opinion working for one of these "Big Tech" companies can become quite the golden cage. If you're able to get in, working for one of these companies usually comes with very high total compensation (€250k total comp a year is not unheard of check: techpays.eu). In addition these companies usually offer great secondary benefits like catered lunches, free gym access, contribution to health care, etc. And you'll probably be working with the best suited hardware and tech stack for the job. However, it also tends to come with very high internal competition (e.g. for promotions), worse work-life balance (no 9-5 for sure) and generally less job security (PIP anyone?). I'm not even mentioning the fact that with the job market as is, it might not be easy to find another job for a comparable salary. Making it a golden cage. One category I didn't mention but is a honorable mention: start-ups. This is probably the place where you won't get great a great base salary, but might get some meaningful equity. However, given that most startups fail the equity might never be worth something. Hence total compensation is difficult to determine. Therefore, it's a gamble that has a slim chance to pay-off big time. But if you're seeking stability and a healthy work life balance, stay away. It's well known that start-ups can be a stressful place to work that put a high demand on you. Nevertheless, having worked in a startup does give you a unique perspective. In my opinion it's all a delicate balance between many factors, where compensation is just one of them. Having a family for me work-life balance is more important, but this might be dependent on your life stage. My advice, stepping out of a golden cage into something different (entrepeneurship, freelance, startup, local champions) can be great options, it's just a matter of what's important. What is your take on all of this? Curious to hear your thoughts. #goldencage #compensation #techsalaries #bigtech #Netherlands #tech

18

🚀 Join us for an exciting live session on 𝑴𝒐𝒃𝒊𝒍𝒆 𝑨𝒑𝒑𝒍𝒊𝒄𝒂𝒕𝒊𝒐𝒏 𝑴𝒐𝒅𝒖𝒍𝒂𝒓𝒊𝒛𝒂𝒕𝒊𝒐𝒏 with 👾 Tjeerd In 't Veen https://lnkd.in/eg2hcCkG Are you looking to deepen your understanding of modularization and its critical role in modern app development? Don’t miss out on this insightful discussion where we'll cover: 🔍 𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 𝐌𝐨𝐝𝐮𝐥𝐚𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧: What does it mean to modularize a mobile app, and why is it crucial for today’s development landscape? 🔍 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 𝐟𝐨𝐫 𝐂𝐨𝐝𝐞 𝐑𝐞𝐯𝐢𝐞𝐰: Discover effective strategies for conducting code reviews in feature modules, ensuring high-quality code and smoother collaboration. 🔍 𝐁𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠 𝐋𝐞𝐠𝐚𝐜𝐲 𝐚𝐧𝐝 𝐍𝐞𝐰 𝐌𝐨𝐝𝐮𝐥𝐞𝐬: Learn how to progressively transition from legacy systems to a modular architecture while continuing to deliver new features. 🔍 𝐌𝐞𝐫𝐠𝐞 𝐂𝐨𝐧𝐟𝐥𝐢𝐜𝐭𝐬 & 𝐕𝐞𝐫𝐬𝐢𝐨𝐧 𝐂𝐨𝐧𝐭𝐫𝐨𝐥: Get practical tips on managing merge conflicts, version control, and maintaining consistency across different modules. Whether you're a seasoned developer or just starting out, this session is packed with valuable insights that can take your skills to the next level. 🕗 Time: 1 PM (Paris, France) 🇫🇷 / 1 PM (Amsterdam, Netherlands)🇳🇱 📍 Location: Only on Swift Academy 🇹🇳 See you there, and may the code be with you! ----------------------------------------------- 🚀 Support my work if you'd like! ☕️: Buy Me a Coffee https://lnkd.in/ei7cVejt 📨 Don't forget to subscribe to the newsletter of our site Swift Academy - Modern Mobile Development. https://lnkd.in/eUvvBk46 🎥You can also subscribe to my Youtube channel https://lnkd.in/eHKCft-E #MobileDevelopment #Modularization #CodeReview #VersionControl #AppDevelopment #TechTalk

36

Last week, I wrote about the easiest way to try out the Xflow API. Curiously, the top question I received in response was what does a user-engineer really do at Xflow? Well read on, dear friends. I was introduced to the concept of a user-engineer at Stripe (disclaimer: Stripe builds payments infrastructure and is my former employer). Naturally, my understanding of what a user-engineer does at Xflow is influenced by my time at Stripe. When Mathan Appadurai and I were discussing how we should go about hiring for Xflow's first user-engineer, we realized how this role isn’t sought after within infrastructure companies in India. Needless to say, this surprised me. I believed and still continue to believe that user-engineers are crucial to the success of any company building and operating critical infrastructure (one of the things I’d love to do through the work that we do at Xflow is raising the profile of a user-engineer and making the role more appealing for interested individuals). To me, a user-engineer plays 3 different roles, which I have articulated below. Companies like Stripe, which operate at scale, have specific individuals for each of these roles. At Xflow, given we are early in our journey, the 3 roles are played by a single individual (!) with periodic assistance from the product and engineering team. (i) Solution Architect - Focuses on strategic engagements in partnership with the sales team to design and implement solutions that align with a user’s business goals - Builds long-term relationships and drives the adoption of Xflow’s products through high-level solution architecture (ii) Integration Engineer - Manages the end-to-end integration process, working directly with technical teams to implement and troubleshoot integrations - Acts as the primary technical contact for users, providing technical support and feedback to improve product offerings (iii) Support Engineer - Provides level-2 support to users, assisting with application setups, troubleshooting issues, and ensuring optimal functionality. - Works with helpdesk software (example: Zendesk) and escalates complex problems to developers for resolution. Ensures customer satisfaction through effective communication and problem-solving That's a whole lot right? I know it is! When I was at Stripe, I remember thinking how much fun this role was - you get to interact with users, you get to use the Stripe API to problem-solve user asks and help user's out with real-world issues that they are facing and get instant gratification. A significant part of my growth in Stripe was just me continuously trying out the API, answering user tickets and asking a continuous stream of questions in the user support Slack channel (hat tip to Rémi Jannel for answering them!) PS: I've provided a link to the job description for a user-engineer that we used when we were hiring for this role! Feel free to re-use. #payments #paymentsinfrastructure #engineering

38

2 commentaren

☝️ Things I didn't knew CSS could do. ...but now I do! 💡 On the very first edition (and the very first day even) of #FrontendNation, the largest free online frontend conference, I took the virtual stage to talk about CSS. About generous amount of features that were added to the #CSS spec and can replace your #sass or #JavaScript solutions. It's also a talk about learning about knowledge gaps and taking action when identifying them. It's okay to not know every latest technology (and there are plenty in the frontend space), as long as you know what to do if you encounter lack of knowledge. ...and that talk is online, free to watch: https://lnkd.in/eVMi28Fe 🍿

6

Can’t wait for this one to start ☝️ What a wonderful & practical opportunity to learn how to code with the help of AI tools like Replit Bite sized lessons to gradually build that confidence, and better yet with like minded builders. Come & Join me 🔥😍🔥 Thank you Harold D. and Max H. #CodingWithAI

15

4 commentaren

Developers these days are so darned lazy. And cheap. OK, sorry, that was not fair. Developers have always been lazy and cheap. I was really surprised by this when I started out as a software developer, fresh out of college 25 years ago. I noticed that whenever my more experienced colleagues were asked to add new functionality, the first thing they did was to check if there was pre-existing code that did the job. Preferably free. This blew my mind. But as I thought more about it, it made sense. Especially after I attended a Business Strategy class at Southern Methodist University SMU Cox School of Business. Build vs Buy vs Reuse is a part of Business Strategy. Why build or buy something if it is freely available? When we start with something good-enough that is freely available, we can customize it to our needs. And if it is well-maintained, we get free upgrades. This frees up more time and money for us to build things that no one else can build as well as us, which makes customers very happy. It reduced the TCO (total cost of ownership) of our solutions and it increases our EBITDA, which usually makes investors very happy, which makes the board of directors very happy. So it turns out that developers are not only lazy and cheap, but they are also strategic and there is a lot we can learn from them. Especially when it comes to building Software Product Development Lifecycles. You may be tempted to reject the pre-existing frameworks and build your own because none of them are good enough for you. Newsflash! You might think you are unique and special and nobody is solving the specific kinds of problems you are. Maybe yes, maybe no. You are just as unique as every other snowflake. And while you might be doing something nobody else has done before, you don't need to develop your own SDLC. Think like a developer. Be lazy, cheap and strategic. Start with a pre-existing framework, make use of all the free training available on the market, and customize only what you need to. Your EBITDA will go up and your customers, investors and Board of Directors will be happy. You are welcome.

14

4 commentaren

😬 Might be doing something right with Featurevisor (https://featurevisor.com) to attract this many sponsored ads from VC-funded SaaS giants. 🤷‍♂️ Also, Google Search is rotten beyond repair. (Screenshot taken from The Netherlands today, and previously verified with friends from the UK) #featureflags #abtesting #experimentation #opensource #featuremanagement #saas

77

6 commentaren

Pragmatism is the single biggest factor towards success in your career as Software Engineer. If you want to grow fast, think how can you unblock yourself to deliver customer value as fast as possible and in meaningful incremental steps. You receive feedback and adapt your approach to reach the same end goal: That is to “delight your customers”. Putting customers and their problems first and finding innovative sub-solutions would take you to greater heights. The best part? By breaking bigger solution into smaller achievable deliverables, you enjoy the journey, relieve stress from yourself and your leadership and achieve all that while having work life balance. How? Because you only focus on solving next immediate sub-goal and don’t overthink or over optimize things. That’s how you earn trust, given responsibility and then become a leader. —- ♻️Follow along Gourav Khanijoe if you liked this. And use 🔔 to get regular notifications. Link to my newsletter in comments.

15

1 commentaar

How to juggle a developer job, conference speaking and working on SaaS.. at the same time? I recorded my thoughts on this while driving to work this morning Spent 10 minutes editing it on my lunch break And now you can read it! (link in comment)

5

1 commentaar

Developer documentation is something that is difficult to get right and probably impossible to get perfect, but there are things you can do to make your developer docs great. Tomorrow at 1pm ET (UTC -4), Johannes Dienst will share some of the tips and strategies he learned when revamping his company's docs. https://lnkd.in/dJeR3z34

6

2 commentaren

Ever wished there was a magazine dedicated entirely to the exciting world of Kotlin? Well, look no further than the fun code() Magazine! This isn't your average tech rag. This one-time print publication, released just in time for KotlinConf 2024, has quickly become a sensation among Kotlin enthusiasts. Packed with insightful articles by industry heavyweights like Chet Haase and Jesse Wilson, it delves into various aspects of Kotlin development, providing valuable knowledge and fresh perspectives. But wait, there's more! The magazine doesn't just stop at theory. It throws in a fun, hands-on project – a DIY 3D Kotlin logo! This is the perfect blend of learning and creativity, making it a truly unique experience for any Kotlin developer. you can download the magazine on the link bellow! : https://lnkd.in/gC9kqPv9

5

1 commentaar

Let's face it: "software engineers" and "software developers" are *not* craftspeople. We are usually a business cost-center that converts business requirements into customer dollars. Setting aside the political baggage of the Software Craftsperson (nee "Craftsman") movement (and those original words alone convey some of the baggage), I find now that I regret the entire movement itself. Paid software development is about serving a business need and rarely about crafting software that is optimized for flexibility, reliability, and understandability. When businesses seek to turn a need into software, they are often concretely planning for a quarter, loosely planning for a year, and pipe-dreaming when they "plan" for anything over three years. This has an impact on software developers. The cost of converting ideas into software usually scales something like logarithmically to exponentially with the complexity of the business. Software is usually developed with an eye toward achieving a quarterly or annual goal or an investment round--so let's say 3 to 12 month window. Management expects to be able to measure results. And, so, in most environments, you need deliverables that can be demonstrated to management in order to show progress. Except for those ideal cases where eXtreme Programming actually works (e.g., customer is always onhand for clarification, no artifacts other than code and test code, team of up to maybe 8 people, often working in pairs, etc.), the complexity of converting business needs into code is complicated bordering on complex because businesses are complicated bordering on complex. (I use the Cynefin definitions of "complicated" and "complex" where "Complicated" means something like"with a reasonable amount of effort, you can somewhat reliably predict outcomes" and "Complex" means that "this system/business is so complicated that you cannot reliably reason about its properties and so properties and outcomes are emergent) Given anything but a project or business with an exceedingly clearly bounded minimum viable product, we're rarely crafting but instead struggling to meet quarterly/annual/funding round deliverables. But wouldn't it be wonderful if we could find our way back to when software developers were able to ship software they could be proud of and businesses were better for it? Perhaps it's still possible. But we all have to be playing a long game, business and developer.

13

2 commentaren

Stuck in a feature factory? 4x thoughts for better work + less frustration 𝟭. 𝗨𝗡𝗗𝗘𝗥𝗦𝗧𝗔𝗡𝗗 𝗬𝗢𝗨𝗥 𝗠𝗔𝗡𝗗𝗔𝗧𝗘 • Speak with the CEO / your boss / stakeholders • What do they actually want you to do? • Do they want you to be a Marty Cagan style PM? • Or do they just want you to ship stuff? This is important because: • You need to build credibility by doing the job expected of you before you can do anything else. • Complaining that they "don't understand product" will only lead to frustration all round. • Your job isn't really your title. Your job is solving problems for your boss. Let's assume they basically want you to ship stuff. How do you add more value and mature the culture? Read on ... 𝟮. 𝗗𝗜𝗚 𝗙𝗢𝗥 𝗖𝗢𝗡𝗧𝗘𝗫𝗧 You've just been told to build something. What next? • You need to know you're talking about the same thing • You need to build personal conviction to build it well • Don't just take a 1 sentence request and start building • Insist on a kick off, and mine them for context first    Questions to ask: • Why do they want to build this? • What do they expect to happen when it ships? • What references are they thinking of? • How much time do they want to invest in this? • Is this a test to learn, or a scalable solution? • What made them think this is a good idea? • Which risks do they want you to handle, if any? (value, feasibility, usability) Write this all down in a PRD / 1 pager You should all have a MUCH better idea of what you're building now. You should be able to evangelise this to engineers. This will lead to better outcomes all round. 𝟯. 𝗠𝗔𝗞𝗘 𝗜𝗧 𝗖𝗢𝗠𝗠𝗘𝗥𝗖𝗜𝗔𝗟 • PMs help stakeholders make smart investments in technology • Do this by converting feature requests into investment language • Express time to build as a $ cost • Convert expected outcomes into $ impact (where possible) • Calculate expected and actual ROI on the build (where possible) • If you can't calculate ROI, what would someone need to believe for this to be ROI positive? Is it believable? This will: • Make you seem very commercial (always a good thing) • Expose features where the ROI doesn't stack up • Expose big financial risks that could be mitigated with discovery 𝟰. 𝗗𝗜𝗦𝗖𝗢𝗩𝗘𝗥𝗬 𝗔𝗦 𝗔 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 By this point, you should be able to offer "discovery as a service" • Have mistakes been made in the past? • Have you exposed big risks in the feature request? • Suggest ways to reduce risk with some lean discovery • Don't be partisan. Let the stakeholder decide whether they want this. • Discovery is a tool to solve a problem • The problem it solves is excess risk • Highlight the problem (risk) and stakeholders will want the solution (discovery) Hustle Badger is the best place to accelerate your product career with a wiki, courses and community.

136

9 commentaren