Scott Knutti

What separates an average developer from an awesome one? Average developers follow instructions. Good developers write code. Great developers solve problems with code. Awesome developers build systems that solve business problems. Code is a tool, not the end goal. True impact comes from understanding the bigger picture and creating solutions that drive business growth. #softwaredevelopment #engineering #leadership #innovation #tech

31

9 Comments

Can someone explain to me how to get "more experience"? I have 16 years of full stack software engineering experience, mostly in C# .Net 4.2 through 8, including .Net Core 2.x & 3.x, along with WCF, WPF, Winforms, Razor/Blazor, HTML, CSS, and JavaScript, with Entity Framework, Dapper, Linq, SQL Server, MySQL, SQLite, Oracle, NoSql, and other databases. And a few of those years include a combination of Java, PHP, and C/C++. I've also used MarkDown, PowerShell, MVC framework, Swashbuckle/Swagger, Newtonsoft, JSON .Net, TopShelf, and a variety of testing frameworks. But apparently that's not enough. In the past 3 years alone, I've learned ReactJS, TypeScript, Xamarin, XAML, Maui, NodeJS, Terraform, AWS, and Azure, and I'm currently learning Angular, but that doesn't cover the 3-5 years of experience jobs want. I've learned some of these skills through jobs, but also some on my own. Except that as often as companies want us to learn these skills outside of work, they only count professional experience when it comes to hiring. My last interview said I needed more experience, as if the previously mentioned 16 years wasn't enough, and neither was the 15 years of computer repair and networking before that, which their interview questions also covered. So if no one is willing to hire because people don't already have experience, how are we supposed to get the experience? And don't say "open source projects", because they don't count as professional experience. Or do I have to take a 50% pay cut to take an "entry level" job that still requires 3-5 years of experience that I somehow still don't have? People are quick to say that "no one wants to work anymore" when they can't get hired, but they never seem to think "businesses aren't willing to teach anymore" when they refuse to hire people. Why? Is it that we are so conditioned to think that it's always the individuals fault for not living up to expectations, instead of the businesses fault for setting unrealistic and ever changing expectations? So, I ask again, how can I get the required experience when employers refuse to hire unless I already have experience?

2

This video is way too long and rambling but I wanted to brain dump some of the JavaScript functionality I've been developing for quickly prototyping modern HTML applications: https://lnkd.in/gNZgAHc8

6

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

Had a very good experience working on #OpenRewrite these last few weeks with some great engineers including Tim te Beek. I improved robustoness and migration of #Jmockit Expectations, and added JMockit Verifications (v8.29.0) and NonStrictExpectations (v 8.30.0) migration to Mockito. Hope it helps anyone out there migrating from JMockito to Mockito. #java #refactoring #migration

32

2 Comments

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

As someone who builds complex custom elements for massive distributed systems, I want to weigh in on the whole "Web components are <insert opinion>" debate that's been bouncing around. Haven't wheels already been invented, like, at least a few years ago? We're all trying to find the right wheels for the carts we're trying to pull. If the `<button>` element was perfect, we wouldn't need `<input type="button">`, or `<div role="button">` or the unsupported `<button is="custom-button">`, or even the forbidden impostor `<a class="button">`, to render this very basic, yet vastly intricate concept. The fact that we can now create a custom "button" directly in the browser, one that doesn't have the historical baggage of `<button>`, or the baffling rigidity of the jack-of-all-trades `<input>`, is something that should be celebrated. In some cases, we don't even need to include native form elements in our shadow DOM anymore, thanks to the ElementInternals API. ElementInternals handles both ARIA and form association, at a platform level. This means native forms can treat custom elements the same as any other form control, with field validation, label association, and value submission included. It's by no means a perfect solution yet, but it's better than everything we've had before it, and a lot of people are working very hard to make it better for everyone. Framework-driven components literally can't do this. If they claim they can, it means they're either building custom elements wrapped in extra JS, or they're doing a LOT of heavy lifting to reproduce what's already available in the browser. I've always had issues with front end frameworks, which is why I choose not to use them. I find that they make it dangerously easy to dig a hole too big to climb out of, especially when they bring their own abstractions that obfuscate what's actually being rendered on the page. There's too much "magic" that happens, and I don't appreciate the "just trust me, bro" vibes I get from how certain frameworks function (hooks, JSX, etc.). To wrap this up, I can count the amount of times I've had to work professionally with React, Vue, and Angular combined on one hand. I guess the one I used most was Vue, and even then it was only for a few months before I started building custom elements in 2020. I've seen no compelling reason to go back.

38

5 Comments

🎥 Watchlist Highlight: The WET Codebase If you’re looking for a clear explanation of what makes a good code abstraction, look no further than this excellent talk by Dan Abramov. Dan gave this talk at Deconstruct 2019—which, I know feels like decades ago, but the ideas he shares in it are genuinely timeless. You can watch it here 👉🏽 https://lnkd.in/gM4qMsP4 In The WET Codebaes, Dan talks about the dangers of focusing too much on keeping things DRY without considering whether the abstractions we create still make sense, and he shares some key aspects to keep in mind when dealing with any abstraction: 1️⃣ Benefits of abstractions: focusing on intent, code reuse, and avoiding bugs. 2️⃣ Costs of abstractions: accidental coupling, extra indirection, and inertia (for your team.) 3️⃣ Tips for abstracting responsibly: test concrete code, delay adding layers, and always be ready to inline your abstractions when necessary. Dan ends the talk with his recommendations for what to watch next for a deeper dive into this topic. As a big fan of all of these, I strongly +1 Dan's picks and encourage you to add them to your watch list: - All the Little Things by Sandi Metz https://lnkd.in/gNs4NT8h - Minimal API Surface Area by Sebastian Markbåge https://lnkd.in/ghTArZbC - On the Spectrum of Abstraction by Cheng Lou https://lnkd.in/gctJB_We

53

1 Comment

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

For the tech companies building software. If you don’t iterate you will never get to Raptor 3. It’s easy to continually pile on to the first iteration… It’s easy to be a feature factory… Don’t be afraid to take the best and rip out all the failed experiments and/or features with no business value. #software #engineering #modular #contextbounding

21

This is a great blog entry on the "devaluation of frontend" development. https://lnkd.in/gDuGeh7n You should read it. A few passages that jumped out at me: "We often aren’t included at the beginning stages, where we could easily identify costly accessibility, performance, and user experience mistakes; we’re brought in at the end, when things have already been built and it’s too late to change anything significantly." - THIS - I had a job for awhile where I was treated as a fixer/styler in spite of 5+ years at that point as a professional developer working in both backend and frontend languages. It was like getting very skilled at UI work made folks skeptical of all of my backend and regular programming skills. That was in spite of having a math degree and starting my software engineering career as a python developer. Meanwhile, you wouldn't believe the skepticism that we encounter when trying to tell folks that there is a "right" way to build the frontend so that you don't have to go back and fix accessibility problems or cross device issues. Because frontend skills are so devalued, it is very common to just expect a backend engineer to do them regardless of whether they have ANY skill in that area. I've seen it happen many, many times that a person with sometimes LESS than entry level skills on the frontend are just assigned to build new frontend features or make a major UI update. I mean it is literally common for someone who could NOT get hired as a frontend developer to be assigned to build a major new frontend/UI update. To use the building analogy, it's like you suddenly decided your plumber installing your sinks and tubs should be able to handle the installation of windows, doors, shingles, trim and paint. And this bit (https://lnkd.in/gMdmebAj): "Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room." Yes, this. And guess what? Bad HTML and CSS can eat up your time and resources just as surely as any other part of the codebase. But now that you are putting someone on it who doesn't have those skills, like a very expensive backend software engineer with more than a decade of experience, you may be taking many times longer to find and resolve the problem than if you had put someone on it who works with it every day, or that was actually an expert. I mean should you put someone on that UI bug who cost $60/hour and can fix it in 10 minutes or someone that costs $100/hour and can fix it in 6 hours to a week? I am NOT joking about those times. Expertise and skills in one area of the stack, does not magically jump over to others.

4

I wrote a thing about zero-cost abstractions, with a real usage example: https://lnkd.in/g4mSJ52H This is programmer specific, and fairly "beginner level", so feel free to ignore if you're not in a target demo where that might be interesting to you. I wanted to write the blog post, based on some recent interactions, and figured I'd link it here in case it's interesting to anyone it might be shown to.

3

I can’t find it now but our team not long ago had a good laugh at a cartoon panel about a software engineer so exasperated at some syntax heavy quasi-code (Terraform, Webpack, Redux?), they quit and took up wood carving. It was our little joke in the Slacks for a minute. Now that the universe has blessed us with an opportunity for reflection (mass lay-offs), we might revisit that theme a bit more seriously. What does a set of wood chisels cost, anyway? I have been consistently surprised, over a couple decades of interviewing software engineering candidates, at how many are unable to demonstrate real interest in the field. Oh sure, there are platitudes; there’s the performative stuff that is the lifeblood of LinkedIn. But there’s less evidence of internally motivated, quiet, continuous self-improvement. What (software engineering things) did you do in the months since you left your last job? What new things are you currently exploring in the field? If the answer is “nothing,” congratulations, you sound like a normal person. But maybe it also means this is an opportunity to realign if not pivot to find what does spark curiosity for you, what you would love exploring. Maybe more UX programming; or more algorithmic. Few things will make your next job more enjoyable than having enthusiasm for the work.

18

3 Comments

Not specific to coding screens so forgive me for going off-track but I feel like there can be a "you won't always have a calculator" discussion that might be interesting. In regards to open-book or closed-book, it is difficult to remember everything so referencing something you might have forgotten isn't uncommon but there is a distinct difference between refreshing your memory and searching for a solution. However, being able to research effectively is also a great skill. With access to this information so readily available and the growing popularity of AI, I can definitely see engineers trending toward having less technical fundamentals and critical thinking in favor of yielding quick results. Is it efficiency or laziness? Will it be damaging? I'm curious how it will affect the industry.

7

I find interesting the hype about counting downloads for a given tool as a metric for success. I guess it helps to show how popular something is, but I would love it if people also considered other aspects, such as project governance and project activity. Anyway, let's follow the trend (evidence in the comments): - Selenium Java downloads: 98.5M in May 2024 - Selenium active users in the last 30 days: 2.6M. Happy automation!

54

9 Comments

I started out with Fortran, moved on to Python, JS/TS, C#, Go, and then... I’ll be the first to admit that PHP wasn’t high on my list of modern web development tools. Like many, I viewed it as something of a relic. But diving into Laravel has challenged that perception in a big way. Laravel’s out-of-the-box power is remarkable. While Django has been a reliable workhorse with its "batteries-included" philosophy, Laravel feels like it’s taken that concept and supercharged it. The ease of setting up complex routing, authentication and even queue handling in Laravel is genuinely impressive. It’s like discovering a whole new side of PHP that I hadn’t realized was there. But this isn’t just about features, it’s about DevEx. Laravel’s intuitive syntax and the seamless integration with Inertia.js and Vue have been game-changers, offering a smooth, reactive front-end experience that’s tightly coupled with the backend. If you, like me, had reservations about PHP, I’d recommend giving Laravel a go, it's incredible how quickly you can throw a fully fledged application together...

11

"Team" structure at Pacific Northwest National Laboratory is weird, in a good way. I'm used to "join a company, work on a product long-term". It's not like that at all here. It's less top-down and more "get a bunch of talent together and let them do their thing". Like a vetted, well-networked group of entrepreneurial spirits that organically make cool things. My manager isn't necessarily tied to my work. I don't have a desk on campus that is my home, and I don't know if I really want one. If I want to work on something else, I just... talk to people and do it (but I'd get myself in trouble if it was a bad time for my current projects). I get a code that lets me bill my time to that project [1]. My immediate contacts regularly mention, "You should talk to this person, check out this thing, I'll set you up with this person", etc. Networking is the innovative lifestream of the organization, and unusually important for individual career growth. Long-term software maintenance requires explicit funding proposals. I think this means more dead software, but also a healthy focus on what is important. It's very different, and IMO special. I've never felt so proud/excited to be associated with a professional organization. [1] I bill my time on a half-hour basis, every day. For Monday through Thursday this week, I have 11 durations assigned to 4 charge codes. Billing consumes a decent chunk of meeting time and my meat computer's clock cycles.

8

A meta note about this talk: I am, as a lot of folks out there know, not exactly bullish on LLMs in general. I think most of the hype is nonsense—even while I think some of their capabilities are really astonishing!—but I do think they’re here to stay. So: First of all, if we’re going to be working in a world where people are authoring code with LLMs (Copilot etc.) and using them to “do things” as agent-based systems, the world of inputs to the models matters, as do the environments in which they run. They matter a *lot*! Second, I think a lot of engineering organizations pretty consistently underinvest in foundations, because of the simple realities that many kinds of foundations projects take longer and have a less direct/measurable connection to profitability. They just do, no way around it. Third, then, what are the ways that engineering leaders—including managers, but especially Staff+ engineers—can mitigate the risks of LLMs and improve the chances that they are net neutral or even positive, rather than negative, for software quality, UX, and business outcomes? Secretly (and yes, I am saying it out loud now!) it is predicated on my belief that THESE ARE THE THINGS WE SHOULD BE DOING ANYWAY… but this is a moment when we have a really obvious reason how and why these things matter, with which we can make that case to decision-makers. And because these are the things we should be doing anyway, an organization which uses this LLM-hype-moment to improve the foundations on which we run LLM-related systems… will be in a better spot two years from now *even if the LLM ecosystem craters*. Seems like a win.

10