Matteo Monti

Come la vedete voi? C'è un post su #HackerNews che mi ha fatto pensare... Hi. I've been in the profession (SW Eng) for about 18 yrs now. A few years from my 50s. Didn't go the managerial route. Stayed technical. My current gig is in a very difficult and complex project written in C. Been there for 2 yrs now and I'm afraid that due to the ancient tech stack and despite being a good engineer I'm loosing my marketability. After enduring bad behavior for nth time (yeah it's a toxic workplace) I decided I had enough and did a round of applications. Mostly for backend positions and mostly for golang positions. I don't have prod xp with golang but it's close to C and every time I've used it it seemed ok. But the problem is that I'm either being ignored or skipped over. All jobs are for seniors in the _specific_tech_stack_. Other positions I've applied for and got no response whatsoever are architects, tech managers and the like. Granded, this regards a turd job market (EU/Greece) but still that's where I am at. Am I toasted for good? I mean, nearing my 50s with my most recent gig writing "C" on it is as good as declaring my career over? Link nel primo commento...

14

16 commenti

🚀 Unlock the Power of C4 Model Diagrams! 🚀 Hey #Developers and #Architects! 🛠️ Are you looking to elevate your software architecture game? Check my latest article on the C4 Model! 🌐 🔍 This article can be particularly useful for Software Architects, Tech Leads, and everyone who wants to have a clear view of the architecture of a system 📚 4 Topics you will find in my article: 1️⃣ Overview of the C4 Model: Learn the basics and why it’s a game-changer for software architecture. 2️⃣ Install and use Structurizr on Windows (with Docker): Understand how to run Structurizr in any system that can use Docker. 3️⃣ Step-by-step guide: Understand how to visualize your system’s modules and their interactions using Structurizr's DSL. 4️⃣ Practical Tips with Structurizr: Get hands-on advice for creating C4 diagrams using Structurizr. Don’t miss out on this insightful read! 📖✨ #SoftwareArchitecture #C4Model #TechLeadership #Coding #Structurizr https://lnkd.in/dWvWKF_D

12

Italians will say "Il bello della diretta" which - in this case - can be translated into "The fun of live coding". This is a beautiful video about the power of GitHub Copilot and how it can help you not only when you are already able to coding on a specific language, but also in case you really don't have any expertise on that. The author shows how to deal with a Python application without knowing anything, not only from live coding point of view (you write what you want and he produces the code) but also from a live prompt where you can ask less concise questions and wait for a nice reply. There is two sentences the author affirms that we need to focus on when approach on Github Copilot: 1. You are always responsible for the code you will push. Copilot is just an assistant, a co-worker for pair programming. But you are the owner of the code and you need to take always care about correctness and quality 2. Every time you use it, you can receive different suggestions, so do not trust on predictability for produced code At the end of the speech, there is also a nice overview about the Enterprise Version, which means that - not only but for me it is the most relevant thing - you can train your Copilot with your own codebase and he can learn from that (especially for internal API, catalogs and so on). The last fragment of the video shows also a study on impact of Github Copilot: it seems to reduce the develop time of 55% and increase of 90% the joy of coding for programmers. I personally don't think 55% is a percentage that can be reached because - for me - reducing the time of producing code means that I can focus more on code quality and tests. So even if you reduce of 55%, you will spend 30% more time to improve what I said, so give you the math (and remember that more quality means also less bugs and less rework) Take a look https://lnkd.in/dbRVUGTR

2

REST is not just about CRUD; it is defined in the paper "Architectural Styles and the Design of Network-based Software Architectures" by Roy Thomas Fielding. One of the properties described in the paper is ‘Code on Demand,’ where the client can request a script or binary from the server (similar to what happens when a browser requests JavaScript files to extend the behavior of a web page). This concept is powerful, but it’s not exclusive to the web world. In this post, you can see the same concept applied using #Qt. #systemdesign

1

My take: software engineers will still be much needed in the era of LLM-aided software development. Their role may evolve, but their contribution will be indispensable. Here's why: - Software engineers are coming up with novel and useful design patterns for LLM based architectures. This shows that humans already started "abstracting themselves away" from the thinking plane that LLMs are overtaking. - LLMs will enable small engineering teams to construct incredibly complex solutions, heralding another golden era of software engineering. Together with AI, humans will be building *more* software, not less.

43

3 commenti

A monolithic architecture is a choice, and a valid one at that. I’d go further and say that in my opinion it is the sensible default choice as an architectural style. In other words, I am looking for a reason to be convinced to use microservices, rather than looking for a reason not to use them. -- Sam Newman. Building Microservices.

5

Do you know four reasons to use asynchronous images? Here are my four. 1.   Performance Optimization 2.   Reducing Memory Usage 3.   Bandwidth Management 4.   Enhancing User Experience If you are interested how use it in iOS. #iosdev #swiftui #swift https://lnkd.in/dXEdcd42

2

How to think about serverless services? How to apply business requirements to build your system? I am talking to Luca Mezzalira, Principal Serverless Specialst at AWS about Thinking Serverless https://lnkd.in/dgrNzwjx #serverlesscomputing #serverless #aws #lambda #eventbridge #solutionarchitect

2

Choose refactoring over rewriting, unless you are well prepared for these: ==== 1. Everything takes longer and costs more We chronically underestimate the effort required to reimplement existing functionality in a new architecture. Even with the best-laid plans, unforeseen complications inevitably arise. Changing requirements, unexpected dependencies, and scope creep can stretch initial timelines by months or even years. Meanwhile, the opportunity cost is immense as new feature development grinds to a halt, leaving the business unable to respond to market needs. Data migration poses a particularly thorny challenge that's easy to brush over during initial planning. Rearchitecting datastores and schemas requires carefully mapping and migrating every data element while maintaining compatibility between old and new systems. Comprehensive migration testing is a project unto itself. Budget overruns are all but guaranteed as these "minor details" end up consuming major engineering resources. 2. Subtle knowledge gets lost in translation Mature software contains a wealth of wisdom in the form of edge cases, bug fixes, and subtle behaviors accumulated over years of real-world usage. While happy path functionality is usually well-understood, the long tail of nuanced behaviors is rarely documented in detail. When rewriting, it's almost inevitable that some of these subtleties will be missed - often not discovered until the new system is in production. Even with the most diligent QA, flipping the switch on a completely rebuilt system is always a nerve-wracking experience. Unexpected issues have a way of cropping up at the worst times, sending teams scrambling to fix showstopper bugs while stakeholders wonder why the new system seems worse than the old one. The fact is, it's nearly impossible to achieve true parity with a battle-tested codebase within any realistic rewrite timeframe. Some degree of regression is inevitable. 3. The human toll is high Rewrite projects are notoriously high-pressure environments. As timelines slip and stakeholder patience wears thin, teams often find themselves working unsustainable hours for months on end. Burnout and churn become endemic, further undermining velocity. Recruiting for long-running rewrites is challenging, so teams frequently end up understaffed. Those who remain must shoulder an ever-increasing workload with no end in sight. In any multi-quarter / year project, shifting company priorities pose a constant threat. What began as a strategic imperative can quickly become an expensive distraction in the eyes of new leadership. Funding gets cut, deliverables get descoped, and engineers grow demoralized as the vision they signed up for appears increasingly unattainable. Many grand rewrites end up abandoned partway through, having burned untold engineering effort for little gain. #softwareengineering #softwaredesign #techlead #softwarearchitecture

31

1 commento

There’s a fascinating ‘leaked’ PDF[1] doing the rounds at the moment. It, allegedly, was penned by Mr Beast, and in it, he outlines key factors for success at his production company. I’d recommend reading it as he speaks with great candour, and it’s packed with broadly applicable insights, but my personal favourite is this: === USE CONSULTANTS Consultants are literally cheat codes. Need to make the world’s largest slice of cake? Start off by calling the person who made the previous world’s largest slice of cake lol. He’s already done countless tests and can save you weeks worth of work. === Whenever I’ve mentored people who wanted to start out in consultancy, I’ve always said the same thing: a consultant is just someone who’s done something at least once more than their client. Consultants aren’t there to be smarter than their clients—they’re there because they’ve BEEN dumber. Consultants have already seen and made all of the right mistakes in all of the right permutations, and they’re there to stop their clients from doing the same. Your client CAN DO what you do—you’re not special. It’s just going to take them longer. You’re not hired because you know what to do—it’s because you also know what not to do. You’re not special; you’re a shortcut. 1. https://lnkd.in/eD6SYchZ

111

6 commenti

If you want to see some of the new SwiftUI changes you can see my latest post, to discover how to leverage the newest APIs to design visually appealing features, including: ✅ Rounded Corners: Learn how to implement modern design elements for a polished look. ✅ Custom Tab Bar Settings: Optimize navigation for a seamless user experience. ✅ Efficient List Management: Hide scroll indicators and row separators for a clean interface. https://lnkd.in/d7TRbfnP #SwiftUI #iOSDevelopment #AppDevelopment #UserInterface #Coding #DeveloperCommunity

5

Here is an example of how #IntelliJ inspections/intentions (aka refactoring suggestions) can guide you to a better code and why I prefer "forEach" to "for" loops in #Kotlin. And don't get me started on the meaning of "retry" and UPPERCASE CARGO CULT (see https://lnkd.in/eJsg5yEk).

3

🚀 Unlock the Power of Arc42 for Your Software Projects! 🚀 Hey #Developers, #Architects, and #TechEnthusiasts! 🌟 Struggling with project documentation? 🤔 Arc42 is a template you may want to use! What you'll find in this article: 1️⃣ Comprehensive Guide: Learn how Arc42 structures your documentation, making it future-proof and easy to maintain. 🛠️ 2️⃣ Practical Tips: Get actionable insights on how to implement Arc42 using tools like Confluence, Word, and Markdown. 📝 3️⃣ Detailed Sections: Understand the 12 key sections of Arc42, from Introduction & Goals to Risks & Technical Debt. 📊 4️⃣ Real-World Examples: See how Arc42 can be applied to real projects, ensuring you capture all essential details. 🌐 5️⃣ Free Templates: Access handy templates to kickstart your documentation process without hassle. 🎁 Don’t miss out on this opportunity to elevate your project documentation game! 💪 #SoftwareArchitecture #Documentation #Arc42 #TechTips https://lnkd.in/dWFp9EkQ

3

Modern CSS Techniques – Grid, Flexbox, and Beyond https://lnkd.in/eK6233ZY

5

If you haven't heard: Google deprecates Material Web Components. https://lnkd.in/d5y6VWqD It's important to know: “Material Web Components” and “Material UI” are both libraries used to implement Google’s Material Design in web applications, but they serve slightly different purposes and are part of different ecosystems." "Material UI (MUI) has not been deprecated. It continues to be actively developed and maintained. The library follows a versioning strategy that includes regular updates and a planned release cycle. For example, the latest stable version as of now is v5, with major releases anticipated approximately every 12 months. Minor and patch releases occur more frequently to ensure stability and the introduction of new features and bug fixes." Figured I'd front-end the panic: "Oh no Google is abandoning material, all our React projects are doomed!!!" Y combinator article below:

1