Scott Severtson

It is CRAZY how much weaker OpenAI GPT-4o is at coding from the completions API than GPT-4. I'm not sure if this is the intended result, but very surprising nonetheless. The training recency is very evident, i.e. it knows about much more modern things, but the difference between its logical output is great with GPT-4 just thinking in a much more sophisticated fashion.

5

1 Comment

I've observed this before, but by far the hardest issues to deal with as a higher-level dev are not technical, but people and process related. Technical problems become somewhat easier over time, but people related problems tend to become harder. The corollary to this is that managers (really, decision makers, but these are usually managers) have an outsized impact on how well a business runs, by virtue of their influence on people interactions, and how well they make decisions. Good managers can allow people to focus on their areas of strength (ie: for technical people, doing technical work); bad managers compound issues with process and infrastructure, and divert lots of work effort to trying to deal with people related issues (inclusive of trying to influence management decisions). It's actually mind-boggling how much work product can be effectively wasted by having bad management in place; this can literally by 90%+ of potential optimal work effort. It's also ironic that orgs in this position often are unaware of this, and completely unable to address it (because of the circular and self-referential nature of the underlying issue).

6

Over the last few weeks I've been checking out Playwright, and I have to say, I love it. As a tester, who is not an SDET and really doesn't want to be, Playwright seems to remove much of the mystique and pain of traditional, programming heavy automation solutions. I'm sure there are tons of great reasons for using Selenium, including support for the recently deceased IE, but for a tester who just wants to automate a few simple tests, integrate with Git and perhaps a straightforward CI/CD pipeline Playwright is at least 8 million times easier. I needed to put together a proof of concept for testing a sports administration customer site, and I looked at Cypress first, but didn't really like it and I'm not 100% certain why, it just felt cumbersome. With Playwright it took very little time to have a simple test up and running using Codegen, and yes, I know, we used to scoff at people who used recorders for automation but this is different. Codegen captures the locators and gives you boiler plate in a couple of lines of code. No Xpath, no messing with page elements that may or may not be visible when you run the tests. Just makes life a little easier and even gives you the imports you need. Building that generated code into a simple page object model is also dead easy. I have my URLs, locators and actions in a nice clean page file, and the tests in spec files. This ease of use makes adding a new page much easier than doing the same task using Selenium and Java, and loads less code, which makes me happy. Persisting login is also easy using a global setup file to capture login state, and store it in an auth.json file, with Playwright using that logged in state for each test by default. To run tests for logged out use cases you just point that test at an empty noauth.json file. Could not be easier. Assertions using expect are simple and logical, and in general I feel much more comfortable with Playwright, and far, far more productive. And that's also true for API tests, although it won't be prising me off Postman just yet, I'll definitely be further exploring API tests in Playwright. Playwright also introduced me to VS Code and I'm liking it greatly. Simple integration with GitHub, nice and easy to step through when debugging and simple clean layout. So what does the professional tester world think about Playwright? Good, bad indifferent? I'd be interested to garner opinions from more experienced automation engineers.

4

1 Comment

Developer downtime: don’t overwork your devs. It’s memorial weekend and I’m lazily sitting on my porch. My kids keep coming in and out of the house, but get stuck because the sliding door keeps coming off the rails and won’t open. Well, since I’ve got nothing else scheduled for the afternoon I investigate the issue. Turns out sliding doors have a bunch of adjustment screws. I adjust them till the door slides smooth. Left in the broken state my kids learned to hit top left side of the door before opening it. Bringing this back to work, I know customer success teams that have a cheat sheet of these maneuvers. Give devs space to observe, we naturally fix these issues.

15

1 Comment

Java 17 has some great improvements in GC as apparent in this poc. Worth upgrading applications and seeing how much impact you observe! POC Highlights: 1. GC frequency reduced from 800 to 100-150 events 2. GC time reduced by 50% 3. GC triggers at 5 GB compared to 2.5 GB in Java 8. This shows Java 17 uses memory optimally. https://lnkd.in/gVQG6tg8 #java #gc

82

3 Comments

Not sure why the Vue community was and (pretty much) is, scared of the composition API. I was too, to be honest. But I have loved it for the past few weeks as I use it more and more. If you are still hanging in limbo, there is a great series on Laracasts by the great Jeffery Way, himself. There are also a couple of free courses on Vue School for Vue3 composition API. You should be up and running in 2-3 days if you have used Vue 2 in the past. #vue #vue3 #compositionapi

25

8 Comments

I often participate in interviews and, more often than not, encounter a fairly predictable set of questions. However, there’s one question that really stood out to me: "What advice would you give to help me grow in my career, no matter where I end up?" This was a fantastic question, and I relished the opportunity to answer it because the advice is both simple and powerful: Be proactive in everything you do. Don’t sit back and wait for problems to come to you; seek them out and tackle them head-on. Collaborate with others to find solutions. Your career will flourish when you take the initiative to identify and resolve issues. This proactive approach not only accelerates your growth but also hones your ability to tackle larger and more complex problems over time. There’s never a downside to being proactive and being the one who solves meaningful problems.

20

I keep hearing the idea that pull requests are bad and that developers shouldn't do them. Well, to me, most of these arguments are somewhat of a straw man variety and they encourage throwing the baby out with the bathwater. Pull requests aren't the problem. Pull requests won't prevent you from doing continuous delivery. The problem is pull requests that take a long time to review and approve. This is the thing that will prevent you from doing continuous delivery. But this is a very avoidable problem. It doesn't have to be this way. In our team, PRs don't normally take long to review and things in the trunk are being updated regularly. So it was in my previous team in my previous place of work. I worked in at least three different teams where we would try to get rid of PRs to see what will happen. In all of those cases, we had to get back to doing PRs because removing them caused more problems that we were trying to solve by removing them. I get it. It may work for some teams that do pair programming all the time, which I see as the only way to keep the code quality up without the PRs. However, this approach will not suit every company and every developer. Many developers I know will find it exhausting having to pair-program all the time. Even when you pair program, PRs still have their use. Just before you push all those commits you created, you can create a PR to view all the challenges to make sure you haven't missed anything. You will not only be able to verify that no temporary code changes go in, but you will also create a nice audit trail of who made the change and who reviewed it. I even sometimes create a PR for my own changes because because it's a tool that makes a pre-push verification very convenient. PRs are just a tool. Just like any other tool, it can either be used or misused. It only causes problems when it's misused and not when it's used properly. This tool may not be useful to you, in which case you may discard it. But you may also find out that it's not as useless as some people say it is and it won't stop you from doing continuous delivery, as these people say.

38

26 Comments

The term “Developer Ecosystem” has been rolling around in my brain lately, so let’s discuss. Here’s the problem I’m noticing. The term #developerexperience is experiencing a similar problem to the term #technicaldebt. It correctly explains the problem for folks who have experience working in software and organizational systems that are inefficient and ineffective. The struggle of just getting good work out the door is real, and we know how we could make things better. We get it, so using these terms feels good because we finally have a phrase that describes a more abstract concept that we feel is important. But the value we feel in using these terms in our familiar domain doesn’t quite translate to people who don’t have experience working as or with software developers. The meaning gets lost in translation and the people who have the most influence into what organizational initiatives get funded can’t conceptualize the benefit. As I’m observing the trends in the #devex movement, I’m seeing that metrics like DORA, SPACE and the DevEx Model are highly focused on an *integrated* experience, not an *individual* experience. It’s about ensuring developers are working in concert with the organizational system instead of fighting it. The struggle is often strong and significant, but it’s easy to think it’s trivial if you haven’t been there. This nuance is pretty hidden, so it’s understandable when it gets glossed over or misinterpreted. I think this is why folks in other domains think about DevEx as emphasizing the productivity of individuals or assuming that devs want to be pampered and treated better than their colleagues. I’m curious if framing the overall problem as ecosystem health would help influence change. Would CEOs and CFOs grasp and fund initiatives more? My hunch is yes after so many years of selling the value of modernizing legacy systems, but I’m curious to hear your thoughts.

10

10 Comments

I'm reaching out to those recruiters in my network to ask about the state of the recruitment market, both for general software engineers and in particular #XR roles. What I'm particularly interested in is knowing more about how many roles are being offered as hybrid or fully remote vs. in office roles. It feels like since the pandemic, the shift to remote working had become accepted by most organizations as being productive, effective and trustworthy. However, there were more recent signs from big tech that they wanted to roll back on this. What is the current state of play? Please chime in. If roles are hybrid, how many days are typical back in the office? Does the mix of hybrid / remote / in office roles correlate with seniority, company size, etc?

2

3 Comments

Just one month until my talk at KCDC: "Testcontainers: The Secret Weapon of Modern Software Development". Come listen and learn some cool things about automated testing with Containers! https://kcdc.info #KCDC #Testcontainers #Docker

44

1 Comment

Another thing I do is track my time, religiously. Every single bit of "work" time I spend is tracked by client (which is sometimes my own company), project, and task. This makes it easy for me to see what I was doing, when, who it was for, and how long it actually took. I can also generate reports to see how much time I spent on certain types of tasks, including mundane things like "Processing" (which includes email, Slack, etc.)

5

I’ve been having a few discussions with TDD aficionados.  We talked about whether they use TDD all the time. It appears that there are instances, particularly in graphical applications, where the test/evaluation is done post coding.  For example, rather than write an automated  test for an object’s depiction, they code and see whether the object appears correct. It was suggested that there may be other times when TDD might be less applicable.  For example, in a pool program, one needs to calculate the result of two balls colliding.  The inputs are the balls’ positions and velocities, and the outputs are the balls’ new velocities. (One could add angular velocity to make it a little harder.) So, I offer this as an interesting problem. Can this function be developed by TDD?  If so, what are the steps? Daniel Moka Al Shalloway Rob Myers Justin Beall Tim Ottinger John Crickett

5

38 Comments

Corporate IT has no place on the path to production. I see LOTS of portcos that hold onto shortcuts they took when they were small. Corp IT runs Jira, or email goes out through the corporate mail gateway. Call it technical debt if you like, and taking on technical debt makes sense when you're a startup. But when you've made it past that stage, it's time to pay it down. Corporate IT is incredibly valuable. I was the Director of IT before I decided to dedicate my career to production web operations. I knew my CDW rep very well. Corporate IT can handle: corporate email, Salesforce, Tableau, calendaring, Zoom, Dropbox, etc. Corporate IT cannot handle: production SMTP gateways, Jira, Confluence, GitLab, Launch Darkly, Datadog, Cloudbees, etc. I don't care in the slightest which actual vendors you use for these functions. I've seen corporate IT change SCMs to "save money" without any input from engineering and set the entire organization release schedules back by more than 8 months because it turns out that GitHub "runners" have security concerns. People have made changes to corporate email and suddenly customers no longer receive notifications, and no one in engineering knows why. Engineering (including Operations) is where the money is made in a software company, and they need to own the path to production. Think of it in terms of "chain of custody" considering the concern over supply chain attacks. In the chain of custody, we don't just let someone with completely different concerns handle evidence. Why would you? #devops #sre #engineering

63

11 Comments

Karl Scotland is one of the smartest people out there on lean/kanban/agile software planning and development processes. While #DevOps dominates the conversation in this space, it's important to remember that the 1st of the 3-ways of DevOps is "flow". These rules are the key to achieving flow.

6

Everyone keeps talking about Pair Programming but I’m not sure I’m ready for it. I already know C#, TypeScript, JavaScript, PHP, KSH, COBOL, JCL, and a few others. I’m not sure I have room in my brain for another language! Is Pair supported by the .NET framework or is it part of the Node ecosystem or is it something else entirely? What are its advantages? is it easy to learn? I haven’t seen any job postings asking for it. 😂😂😂 #humor #programming

4

1 Comment