cross-posted from: https://group.lt/post/1926151

> Don't read if you don't want to ruin your day. > > # The One About The Web Developer Job Market > > ## Metadata > - Author: Baldur Bjarnason > - Category: rss > - URL: https://www.baldurbjarnason.com/2024/the-one-about-the-web-developer-job-market/ > ## Highlights > > >Many organisations are also resorting to employee-hostile strategies to increase employee churn, such as forced Return-To-Office policies. > > >Finding a non-bullshit job is likely only going to get harder. > > >• Finding effective documentation, information, and training is likely to get harder, especially in specialised topics where LLMs are even less effective than normal. > > >as soon as you start to try to predict the second or third order consequences things very quickly get remarkably difficult. > > >In short, futurists are largely con artists. > > >you need to do something > Note: ah.. the famous "you need to do something" > >This is not a one-off event but has turned into a stock market driven movement towards reducing the overall headcount of the tech industry. > > >What this means is that when the bubble ends, as all bubbles must, the job market is likely to collapse even further. > > >The stock market loves job cuts > > >Activist investors see it as an opportunity to lower developer compensation > > >Management believes they can replace most of these employees with LLM-based automation > > >Discovering whether it’s true or not is actually quite complicated as it, counter-intuitively, doesn’t depend on the degree of LLM functionality but instead depends entirely on what organisations, managers, and executives are using software projects for. > > >Since, even in the best case scenario of the most optimistic prediction of LLM power, you’re still going to need to structure a plan for the code and review it, the time spent on code won’t drop to zero. But if you believe in the best-case prediction, a 20-40% improvement in long term productivity sounds reasonable, if a bit conservative. > > >The alternate world-view, one that I think is much more common among modern management, is that the purpose of software development is churn. > > >None of these require that the software be free or even low on defects. The project doesn’t need to be accessible or even functional for a majority of the users. It just needs to look good when managers, buyers, and sales people poke at it. > > >The alternate world-view, which I think I can demonstrate is dominant in web development at least, is that software quality does not matter. Production not productivity is what counts. Up until now, the only way to get production and churn has been to focus on short-term developer experience, often at the expense of the long term health of the project, but the innovation of LLMs is that now you can get more churn, more production, with fewer developers. > > >This means that it doesn’t matter who is correct or not in their estimate of how well these tools work. > > >You aren’t going to notice the issue as an end-user. From your perspective the system is working perfectly. > > >Experienced developers will edit out the issues without thinking about it, focusing on the time-saving benefit of generating the rest. Inexperienced developers won’t notice the issues and think they’ve just saved a lot of time, not realising they’ve left a ticking time bomb in the code base. > > >The training data favours specific languages such as Python and JavaScript. > > >• The same tool that enhances their productivity by 20-30% might also be outright harmful to a junior developer’s productivity, once you take the inevitable and eventual corrections and fixes into account. > > >From the job market perspective, all that improved and safe LLM-based coding tools would mean is more job losses. > > >Because manager world-views are more important than LLM innovation. > > >If the technology is what’s promised, the churn world-view managers will just get more production, more churn, with even fewer developers. The job market for developers will decline. > > >they will still use the tech to increase production, with fewer developers, because software quality and software project success isn’t what they’re looking for in software development. The job market for developers will decline. > > >The more progress you see in the automation, the fewer of us they’ll need. It isn’t a question of the nature of the improvement, but of the attitudes of management. > > >Even if that weren’t true, technical innovations in programming generally don’t improve project or business outcomes. > > >The odds of a project’s success are dictated by user research, design, process, and strategy, not the individual technological innovations in programming. Rapid-Application-Development tools, for example, didn’t shift outcomes in meaningful ways. > > >What matters is whether the final product works and improves the business it was made for. Business value isn’t solely a function of code defects. Technical improvements that address code defects are necessary, but not sufficient. > > >tech industry management is firmly convinced that less is more when it comes to employing either. > > >Whether you’re a bear or a bull on LLMs, we as developers are going to get screwed either way, especially if we’re web developers. > > >Most web projects shipped by businesses today are broken, but businesses rarely seem to care. > > >Most websites perform so badly that they don’t even finish loading on low-end devices, even when business outcomes directly correlate with website performance, such as in ecommerce or ad-supported web media. > > >The current state of web development is as if most Windows apps released every year simply failed to launch on 20-40% of all supported Windows installs. > > >If being plausible is all that matters, then that’s the literal, genuine, core strength of an LLM. > > >This is a problem for the job market because if all that matters to these organisations is being seen plausibly chasing cutting-edge technology – that the actual business outcomes don’t matter – then the magic of LLMs mean that you don’t actually need that many developers to do that for much, much less money. > > >Web media is a major employer, both directly and indirectly, of web developers. If a big part of the web media industry is collapsing, then that’s an entire sector that isn’t hiring any of the developers laid off by Google, Microsoft, or the rest. And the people they aren’t hiring will still be on the job market competing with everybody else who wouldn’t have even applied to work in web media. > > >The scale of LLM-enabled spam production outstrips the ability of Bing or Google to counter it. > > >But it gets even worse as every major search engine provider on the market is all-in on replacing regular keyword search with chatbots and LLM-generated summaries that don’t drive any traffic at all to their sources. > > >It’s reasonable to expect that the job market is unlikely to ever fully bounce back, due to the collapse of web media alone. > > >Experience in Node or React is not a reliable signifier of an ability to work on successful Node or React projects because most Node or React projects aren’t even close to being successful from a business perspective. Lack of experience in Node or React – such as a background in other frameworks or vanilla JS – conversely isn’t a reliable signifier that the developer won’t be a successful hire. > > >Lower pay, combined with the information asymmetry about employer dysfunction, would then lead to more capable workers leaving the sector, either to run their own businesses – a generally dysfunctional web development sector is likely to have open market opportunities – or leave the industry altogether. This would exacerbate the job market’s dysfunctions even further, deepening the cycle. > > >The first thing to note is that, historically, whenever management adopts an adversarial attitude towards labour, the only recourse labour has is to unionise. > > >As employees, we have nothing to lose from unionising. That’s the first consequence of management deciding that labour is disposable. > > >Diversifying your skills has always been a good idea for a software developer. Learning a new language gives you insight into the craft of programming that is applicable beyond that language specifically. > > >But the market for developer training in general has collapsed. > > >Some of it is down to the job market. Why invest in training if tech cos aren’t hiring you anyway? Why invest in training your staff if you’re planning on replacing them with LLM tools anyway? > > >After all, as Amy Hoy wrote in 2016: > > > Running a biz is a lot less risky than having a job, because 1000 customers is a lot less fragile than 1 employer. > > >The tech industry has “innovated” itself into a crisis, but because the executives aren’t the ones out looking for jobs, they see the innovations as a success. > > >The rest of us might disagree, but our opinions don’t count for much. > > >But what we can’t do is pretend things are fine. > > >Because they are not. > > Thoughts?

Highlights

>COBOL remains crucial to businesses and institutions around the world.

>It is estimated $3 trillion in daily commerce flows through COBOL systems, while 95% of ATM swipes and 80% of in-person banking transactions rely on COBOL code.

>when unemployment claims suddenly spiked due to the pandemic, these archaic systems could not keep up, which means that benefits are not being distributed.

>The spike in unemployment claims exposed another new problem: there is no one around to repair these legacy systems.

>Although a few universities still offer COBOL courses, the number of people studying it today is extremely small.

>COBOL Cowboys’ business model is more akin to the gig economy rather than to that of the companies at which these industry veterans spent their careers. It is staffed with mostly older freelancers, everyone is an independent consultant, and there is no promise of any work. The company’s slogan is “not our first rodeo.”

>“A lot of us want to spend time with our grandkids, but we also want to keep busy.”

>Hinshaw was in contact with the state of New Jersey at the beginning of the current crisis, and quickly saw that the unemployment claims issue wasn’t a back-end problem. Every claim that was sent to the host (the back-end mainframe) was processed.

>“They all have the same problem on the front end,” says Hinshaw, adding that these organizations’ Web sites were not designed to handle that kind of volume, while the back-end mainframes typically can.

>IBM, which sold many of the mainframes on which COBOL systems run, has been scrambling to launch initiatives in order to meet the urgent need for COBOL programmers to address the overloaded unemployment systems.

>While these measures should eventually help to alleviate the shortage in COBOL programming expertise, it is clear that the past approach of “if it isn’t broken, don’t fix it” has contributed to the current problem.

Are you learning COBOL already? ;)

Good before going to bed on Friday evening :)

Some things I have noted:

>Until this day, I say I've done three things: insert levels of indirection, trade off space and time, and three, try to get my clients to tell me what they really want.

>If you're doing something with ERP systems, well, first of all, I apologize and feel bad for you in life, but that's a whole other conversation.

>Let's think somebody ultimately is paying for this thing to be built. Somebody somewhere has a vision on what they want it to be. There are humans who will eventually be using it. It needs to meet those business or mission needs. It has to start with that.

>what bothers me is when people make implicit assumptions and don't make them explicit.

>"The decisions that you make upfront are the ones that," and this is paraphrasing, "the ones that are too expensive and you cannot change later."

>But I'm talking about when you make a decision, write it down, make an architectural decision record. It can be itty bitty, itty bitty. But just Tracy made this decision today. Context, we don't have a license for that and it's going to take eight months to get the new license or acquisition or whatever else.

>The other thing that struck me about your example about the people doing the two front ends, and I'm going to use this to loop back into the conversation about developers and architects, is that they don't understand, or appear not to understand, that in the global perspective, by picking two different UI designs, you've made the programmer hiring decision harder.

>I've had a lot of contentious conversations with folks who say, "I'm a solution architect." Well, what technologies do you dabble with? Well, I haven’t touched code in about 20 years.

>It's, if you're going to be an architect and have that mindset, you need to be able to go from the boiler room to the boardroom. You need to be able to communicate, but it also means that in order to be trusted, you have to bring your chops to the table.

>I think lack of taxonomy is probably one of the killers in any organization. You and I don't agree on what that word means. And with that comes so much nuance and with that comes muscle memory and process issues. That's something that just drives me crazy on a daily basis.

>So I am a real junkie when it comes to people talking about how processes don't work. Well, let's have an hour conversation. Let's map out how it's actually working. I'm not talking about Lean Six Sigma values. I'm talking about, let's find the waste.

>One of the things that I would have people to take away is the need to constantly be considering how you can decouple or loosely couple things, because that aids in the longevity. If you think about even electronics and things that you bought in your house, the big integrated front of your dishwasher, I now have to replace the entire dishwasher.

>Because back in my day, full stack meant you are actually worth your salt.

>My way is not always the right way. Don't let anybody hear that, but it's true.

Yea or Nay?

Could be fun ;)

A nice cheatsheet/summary for software architecture

What is your favorite paper from 2013 or earlier published at a SIGSOFT-sponsored software engineering conference (e.g. ICSE, FSE, ASE, ISSTA, ...)?

You can nominate it for an ACM SIGSOFT Impact Paper Award!!

https://sigsoft.org/awards/impactpaper/

\#sigsoft #icse #ase @SIGSOFT @softwareengineering

Even sourcing, cqrs and friends and a take on YAGNI

cross-posted from: https://group.lt/post/321290

> >This talk covers the origins of flame graphs, how you can create them using open source software, and how to interpret them. In practice, flame graphs don’t always work completely due to problems walking stack traces, resolving symbols, and other issues; this talk explains the problems and shows you the latest techniques for fixing them.

cross-posted from: https://group.lt/post/320665

> Joe Duffy discusses the challenges (and solutions) met while running IaC and how that shapes the future of IaC.

Mark Richards' long running series on software architecture comes in bite-sized videos running about 10 minutes.

I was just able to follow the @softwareengineering lemmy via Mastodon.

Three hurrahs for federation!

> The point of this blog post is that, although most of us don’t work on software that would directly be considered safety-critical, we live in a world that’s becoming increasingly automated and computerized, and sometimes, bugs in seemingly mundane pieces of code, even web apps, can cause real-world suffering and harm, particularly when they go unfixed for weeks, months or even years.

> In May 2023 over 90,000 developers responded to our annual survey about how they learn and level up, which tools they're using, and which ones they want. > ... > This year, we went deep into AI/ML to capture how developers are thinking about it and using it in their workflows. Stack Overflow is investing heavily in enhancing the developer experience across our products, using AI and other technology, to get people to solutions faster.

NOTE: This is primarily an invitation for the "SEI and White House OSTP to Explore the Future of Software and AI Engineering", but there is this big section on the "future of software engineering" that is very interesting.

!Software Engineering Research Roadmap with Focus Areas and Research Objectives (10-15 Year Horizon)

> As discussed in Architecting the Future of Software Engineering: A Research and Development Roadmap, the SEI developed six research focus areas in close collaboration with our advisory board and other leaders in the software engineering research community > ... > AI-Augmented Software Development: By shifting the attention of humans to the conceptual tasks that computers are not good at and eliminating human error from tasks where computers can help, AI will play an essential role in a new, multi-modal human-computer partnership... taking advantage of the data generated throughout the lifecycle > > Assuring Continuously Evolving Software Systems: ...generating error-free code, especially for trivial implementation tasks... generating surprising recommendations that may themselves create additional assurance concerns... develop a theory and practice of rapid and assured software evolution that enables efficient and bounded re-assurance of continuously evolving systems > > Software Construction through Compositional Correctness: ...unrealistic for any one person or group to understand the entire system... need to integrate (and continually re-integrate) software-reliant systems.. create methods and tools that enable the intelligent specification and enforcement of composition rules that allow (1) the creation of required behaviors (both functionality and quality attributes) and (2) the assurance of these behaviors at scale > > Engineering AI-enabled Software Systems: ...AI-enabled systems share many parallels with developing and sustaining conventional software-reliant systems. Many future systems will likely either contain AI-related components, including but not limited to LLMs, or will interface with other systems that execute capabilities using AI... focus on exploring which existing software engineering practices can reliably support the development of AI systems and the ability to assess their output, as well as identifying and augmenting software engineering techniques for specifying, architecting, designing, analyzing, deploying, and sustaining AI-enabled software systems > > Engineering Socio-Technical Systems: ... As generative AI makes rapid progress, these societal-scale software systems are also prone to abuse and misuse by AI-enabled bad actors via techniques such as chatbots imitating humans, deep fakes, and vhishing... leverage insights from such as the social sciences, as well as regulators and legal professionals to build and evolve societal-scale software systems that consider these challenges and attributes. > > Engineering Quantum Computing Software Systems: ...enable the programming of current quantum computers more easily and reliably and then enable increasing abstraction as larger, fully fault-tolerant quantum computing systems become available... create approaches that integrate different types of computational devices into predictable systems and a unified software development lifecycle.

> Conclusion: Four Areas for Improving Collaboration on ML-Enabled System Development > >Data scientists and software engineers are not the first to realize that interdisciplinary collaboration is challenging, but facilitating such collaboration has not been the focus of organizations developing ML-enabled systems. Our observations indicate that challenges to collaboration on such systems fall along three collaboration points: requirements and project planning, training data, and product-model integration. This post has highlighted our specific findings in these areas, but we see four broad areas for improving collaboration in the development of ML-enabled systems: >Communication: To combat problems arising from miscommunication, we advocate ML literacy for software engineers and managers, and likewise software engineering literacy for data scientists. > > Documentation: Practices for documenting model requirements, data expectations, and assured model qualities have yet to take root. Interface documentation already in use may provide a good starting point, but any approach must use a language understood by everyone involved in the development effort. > > Engineering: Project managers should ensure sufficient engineering capabilities for both ML and non-ML components and foster product and operations thinking. > > Process: The experimental, trial-and error process of ML model development does not naturally align with the traditional, more structured software process lifecycle. We advocate for further research on integrated process lifecycles for ML-enabled systems.

More: https://conf.researchr.org/details/icse-2022/icse-2022-papers/153/Collaboration-Challenges-in-Building-ML-Enabled-Systems-Communication-Documentation

PS: This one is from months ago, but still interesting

> At Pinterest, Closeup recommendations (aka Related Pins) is typically a feed of recommended content (primarily Pins) that we serve on any pin closeup. Closeup recommendations generate the largest amount of impressions among all recommendation surfaces at Pinterest and are uniquely critical for our users’ inspiration-to-realization journey. It’s important that we surface qualitative, relevant, and context-and-user-aware recommendations for people on Pinterest.

See also: https://group.lt/post/46301

> The repository consists of three layers: > > 1. Finding Category layer lists the overarching categories > 2. General Finding layer lists high-level findings > 3. Specific Finding layer lists low-level findings

Just an overview of the general findings

!General findings

More: https://cmu-sei-podcasts.libsyn.com/a-penetration-testing-findings-repository

> 1. Introduction: What are Miho and its role as a brand; what problem are they solving; how they are solving the problem > 1. Competitive analysis > 1. Logo and Design Guidelines > 1. Information Architecture > 1. Iterations ... in the form of wireframes > 1. UI Designs: Homepage: appealing, informative, and engaging... users could easily know “what” and “for whom” this website is for; Product detail page; Gift Shop Page; Gift detail page; About Page;

> 1. Affectiva's Emotion AI ... facial analysis and emotion recognition to understand user emotional responses > 2. Ceros' Gemma ... generate new ideas, optimize existing designs, ... learn from your ideas and creative inputs, providing designers with personalized suggestions > 3. A/B Tasty ... UX designers to run A/B tests and optimize user experiences > 4. Slickplan ... sitemap generator and information architecture tool > 5. SketchAR ... creating accurate sketches and illustrations > 6. Xtensio ... user personas, journey maps, and other UX design deliverables > 7. Voiceflow ... create voice-based applications and conversational experiences

PS: Sounds like an ad, but still interesting to see tools in the wild that support AI for these conceptual phases in software engineering

> In today’s hybrid work landscape, meetings have become abundant, but unfortunately, many of them still suffer from inefficiency and ineffectiveness. Specifically, meetings aimed at generating ideas to address various challenges related to people, processes, or products encounter recurring issues. The lack of a clear goal in these meetings hinders active participation, and the organizer often dominates the conversation, resulting in a limited number of ideas that fail to fully solve the problem. Both the organizer and attendees are left feeling dissatisfied with the outcomes. > > ... > > The below sample agenda assumes that problem definition is clear. If that is not the case, hold a session prior to the ideation session to align on the problem. Tools such as interviewing, Affinity Mapping, and developing User Need statements and "How Might We" questions can be useful in facilitating that discussion. > A sample agenda for ideation sessions > > Estimated time needed: 45–60 minutes > > 1. Introduction & ground rules (2 minutes) > - Share the agenda for the ideation session. > - Review any ground rules or guidelines for the meeting. > - Allow time for attendees to ask questions or seek clarification. > > 2. Warm-up exercise (5–10 minutes) > - Conduct a warm-up exercise to foster creativity and build rapport among participants such as 30 Circles or One Thing, Nine Ways. > - Choose an activity that aligns with the goals of the meeting and reflects the activities planned for the session. A quick Google search for “warm-up exercises design thinking” will return several potential activities. > > 3. Frame the problem (2 minutes) > - Share a single artifact (slide, Word Doc, section of text in whiteboard tool) that serves as a summary of the problem, providing participants with a reference point to anchor their thinking and revisit as needed throughout the session. > > 4. Guided ideation & dot voting (30 minutes) > - Select 1–2 guided ideation exercises such as Crazy 8s, Mash-up, Six Thinking Hats. A quick Google search for “ideation techniques design thinking” will return tons of potential exercises. > - Provide clear instructions. > - Use Dot Voting and/or Prioritization Matrix to select the most promising ideas. > > 5. Next steps & closing remarks (5 minutes) > - Assign owners or champions for the selected ideas who will be responsible for driving their implementation (if not already known). > - Summarize the key decisions made and actions to be taken. > - Clarify any follow-up tasks or assignments. > - Express gratitude for participants’ contributions and conclude the meeting on a positive note.

After reading this: I know Kung-Fu

Reminded me of Kevin Kelly's book Out of Control

>As the flagship track at QCon, Architectures You've Always Wondered About showcases real-world examples of innovator companies pushing the limits with modern software systems.

Always interesting to see real life design choices.

cross-posted from: https://group.lt/post/65921

> Saving for the comparison with the next year

AI recruitment post as it seems

Kinda cool ;)

>Leslie shares his journey into computing, which started out as something he only did in his spare time as a mathematician. Scott and Leslie discuss the differences and similarities between computer science and software engineering, the math involved in Leslie’s high-level temporal logic of actions (TLA), which can help solve the famous Byzantine Generals Problem, and the algorithms Leslie himself has created. He also reflects on how the building of distributed systems has changes since the 60s and 70s.

>Specifically, we’re diving into a massive migration project by Khan Academy, involving moving one million lines of Python code and splitting them across more than 40 services, mostly in Go, as part of a migration that took 3.5 years and involved around 100 software engineers.

Always interesting to read real world applications of the concepts. Nubank's framework is a mix of storytelling, design thinking, empathy mapping, ...

> storytelling can be used to develop better products around the idea of understanding and executing the “why’s” and “how’s” of the products. Using the techniques related to it, such as research, we can simplify the way we pass messages to the user.

Nubank's framework has three phases:

> 1. Understanding: properly understand the customer problem. After that, we can create our first storyboard. When working on testing with users, a framework is good to guarantee that we’re considering all of our ideas. > 2. Defining: how we’re going to communicate the narrative. As you can see, the storyboard is very strategic when it comes to helping influence the sequence of events and craft the narrative. Here the "movie script" is done. Now make de "movie's scene". > 3. Designing: translate the story you wrote, because, before you started doing anything, you already knew what you were going to do. Just follow what you have planned... Understanding the pain points correctly, we also start to understand our users actions and how they think. When we master this, we can help the customer take the actions in the way that we want them to, to help them to achieve their goals. > 4. Call to action: By knowing people’s goals and paint points, whether emotional or logistical, we can anticipate their needs.... guarantee that it is aligned with the promises we made to the customer, especially when it comes to marketing. Ask yourself if what you’re saying in the marketing campaigns are really what will be shown in the product.

> Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them. > > In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.

---

The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):

• Cloud Infrastructure, which includes cloud computing, scaling, infrastructure as a code, ...
• Pipeline, "important for implementing Deployment Automation and Continuous Integration, and segregating it from the others allows us to make the solutions of these patterns easier to use, namely in contexts where a pipeline does not need to be present."

!Overview of the pattern candidates and their relation

The paper is interesting for the following structure in describing the patterns:

> - Name: An evocative name for the pattern. > - Context: Contains the context for the pattern providing a background for the problem. > - Problem: A question representing the problem that the pattern intends to solve. > - Forces: A list of forces that the solution must balance out. > - Solution: A detailed description of the solution for our pattern’s problem. > - Consequences: The implications, advantages and trade-offs caused by using the pattern. > - Related Patterns: Patterns which are connected somehow to the one being described. > - Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.

Attention economy is a pretty important concept in today's socioeconomic systems. Here an article by Nielsen Norman Group explaining it a bit in the context of digital products.

> Digital products are competing for users’ limited attention. The modern economy increasingly revolves around the human attention span and how products capture that attention. > > Attention is one of the most valuable resources of the digital age. For most of human history, access to information was limited. Centuries ago many people could not read and education was a luxury. Today we have access to information on a massive scale. Facts, literature, and art are available (often for free) to anyone with an internet connection. > > We are presented with a wealth of information, but we have the same amount of mental processing power as we have always had. The number of minutes has also stayed exactly the same in every day. Today attention, not information, is the limiting factor.

There are many scientific works on the topic; here some queries in computer science / software engineering databases:

• IEEE Xplore
• ACM DL
• arXiv

Another related article by NN/g: The Vortex: Why Users Feel Trapped in Their Devices