Dustin McQuay

I was watching a video that talked about what software developers focus on at different stages of their careers, and one notable take was that "Distinguished Engineers" are focused on the *industry*, and not just their company. This is typically because they've engaged with communities outside of where they're working for many years. They say travel "broadens the mind", and learning from and sharing with developers in a wide range of situations tends to give people a much broader sense of software development. Not everything is Big Tech or Fintech or Medtech or Gametech. Not every product is a smartphone app or a website. Not every product has millions or billions of users. (Proportionally, very few do, in fact; so it's interesting how much we obsess over scale.) Not every code base is 100 million lines. Not every code base is 100,000 lines. Not every system has contemporary hardware to run on. Not every platform can accept updates easily (many embedded systems are ship-once). Not every bug or outage is merely an inconvenience (just ask an airline pilot!) Not every product is about profit. And so on, and so on. Learning about what other people, in other roles, in other organisations, in other industries, in other countries, do will tend to make you a much more well-rounded software professional. It will expand your horizons, as well as create opportunities for the wider developer community to have their horizons expanded from your experiences. In particular, there seems to be fairly wide agreement that a "Distinguished Engineer" has made a notable and lasting contribution to the field and the profession of software development. This seems to be encouraged in organisations who pay it forward; who are happy for their most experienced engineers to "share the love" outside of the walls of their business. When a dev, say, creates a testing framework or writes a book or organises a meet-up on their employer's dime, the employer recognises the long-term value of paying it forward. When employers insist developers engage outside of the business entirely in their own time, and entirely at their own expense, those people will usually end up distinguising some other company. And, of course, if that dev-all-the-way-to-the-top career track isn't on offer, then ditto :-)

40

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

Great article by Ray Carnes. In my 20+ years in the software industry I've seen companies learn and relearn the basics again and again because each generation of leaders think things are "different this time" because of such and such technology. The frameworks, platforms, underlying technology changes but the principles and foundations are still the same. #softwareengineering

20

3 Comments

Jake and I sat down and discussed how to avoid failure in your software projects. I think my favorite method for this is the "General Contractor" approach, which leverages a software developer's knowledge of the craft and combines it with the leadership principle of detachment to produce someone who can oversee the software work and ensure it aligns with the business's goals. You can watch a clip of the discussion here: https://lnkd.in/g5J95E2w

1

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

Updated my current project a bit ago and had to take a week off afterwards to rest, but I should share the newest update to the Cash Counter app I'm working on. Got the most bare bones functionality working, the app is now able to track, save, and act as a reliable record for your recent spending or income. Next update should introduce some CSS styling, and then afterwards, potentially before the end of the month, a rudimentary server. Github link is below: https://lnkd.in/ggQq96Zi

2

1 Comment

One thing I noticed when tinkering with greenfield projects after years of working on the same codebase is the number of new tools available today that are lowering the barrier to entry. v0, auth.js, drizzle JS, supabase, neon... The JS ecosystem moves so fast.

22

9 Comments

I'm going to post a few challenges I have had as a software QA. I should be relaxing today but those that know me, know my brain is always in thirty places at once. To developers: Trust your QA. Y'all don't know how many times I've heard, "Well, it works on my local". I don't care. In the test environment, it breaks. I do my due diligence to investigate why, present evidence in logs and from the database, present recordings, and meticulously document steps of reproduction and results. And even after, I still get, "It works on my local". Get off the dang local. NO ONE knows this software, app, platform, etc. better than the QA because we live it more than anyone else does. To business analysts: I know you all are overwhelmed. But please stop copying and pasting Acceptance Criteria for similar features. It makes a mess for developers and QA because the AC doesn't match or conflicts with not only the developed feature but integration as well. Which brings me to my next point... What QA is: Everyone thinks of us as just testers. I am sick of that. I spend half my time working with the product owner, BAs, and Devs, just making sure the AC reflects the solution needing to be resolved. I can't tell you how many times I have had to address with the BAs conflicts in a story over AC, nonsensical AC, WTF verbiage, etc. So then the developers get confused and we are in long meetings addressing what is messed up. We are here to help you ask the questions you didn't think to ask. We don't just test..... we look at future issues too. We like process improvements. Automation: Stop asking me to automate a one-off feature test that hasn't even gone through UAT yet. It's time wasted. Too many companies do this. Might as well give me the day off for the time it takes to do that because the automation is useless after UAT. Learn the purpose of automation. Product Owner: When I tell you before a demo not to demo certain things because there are still issues, don't shred me after the demo because you decided to demo them anyway and they break. I TOLD YOU not to do that, and why. Data: QA worst nightmare. My last position I would get two test records to test against 20 AC when I first started. I said "Helz no". I built up a catalog of test records I could use, positive and negative, as I progressed because I want multiple records against every AC. Which I often shared with the developers for their unit tests who loved it. QA needs data, all. You give me two records, don't yell at me that coverage isn't thorough. Probably sounded more a rant. But I'm opinionated. Where many QA are not. And these are common issues. Want to improve QA, improve the above.

54

34 Comments

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

After a third-of-a-century career as a software tester, I'm done. I'm hanging 'em up. I'm retiring. I'm 58 years old and therefore supposed to call this an "early" retirement. I'm not going to let the nominal age at which I can start drawing Social Security benefits define early-vs.-late, though, so I am not going to use that term. I have no grand retirement plans. My horizon is a couple-three months out - I have a few hobbies, and I'm going to install Jira at home and build a backlog of maintenance and improvement projects* with the intent of not being in a particular hurry to start executing. (*both "home" and "personal", if you follow me) You know what, though - this sounds like the first chapter of some kind of adventure novel. "How did I end up getting involved in <something you'd never think I'd do>," something along those lines. So I'll write it out loud here - I'm way past being the protagonist in a thriller story, but if you need someone to be, like, the guy on the other end of the phone who provides you the information or communication assistance so that *you* can undertake the dangerous and exciting adventure, hey, call me up. A career in software testing leaves me with no special adventuring skills or important influential connections, or anything like that, but at least I'll have some spare time, the need for which, in my opinion, isn't emphasized enough in the description of supporting characters in novels and movies.

92

15 Comments

One of the best ways to get a dev team stuck in analysis or design paralysis is to make them believe they're only getting one shot at it. Because then they'll pack for all contingencies.

49

7 Comments

There’s something for everyone in web development in here:

8

1 Comment

What Does A Chief Software Architect Do? Meet Collins at ClearPath TMS 🙋‍♂️ "Hello everybody. My name is Collins. Next year will mark ten years that I've been working with ClearPath TMS. 💡 My official title is Chief Software Architect, but in practice (while that might imply that I spend my days theory-crafting all kinds of things), in reality... I'm ready to jump in the trenches at any given minute. 🛠 It could be infrastructure-related, It could be the development of features for customers, ⚙ It could be support needs, data management, whatever needs to be done. I'm always ready to hop in, But I do always still find time to be innovating for our customers, 🤝 Allowing the information or the intel that the customer support group brings in from customers - to help evolve the product and give our customers new options and abilities in their system, as well as whatever else may be required, To ensure that they can be successful, and our customer success team can be successful." ⭐ Collins Morley, Chief Software Architect, ClearPath TMS https://lnkd.in/gKewDr2h 🎬 Learn More About Auto Transport AI on ATI https://lnkd.in/ggCwySHB 🚀 Subscribe To ATI Auto Business https://lnkd.in/gT9envUc #automotive #autotransport #software #OEM #shipper #broker #carrier #customer #support #IT

11

3 Comments

"Let's make the talent pool as small as possible!" I just saw a CTO (actual leadership, not "lead developer wtih an enhanced title") job posting, where the recruiter said - in CAPITAL LETTERS (which I'm not going to do because I've got a full driver's license for my keyboard): "Please note, we are looking for XXXX industry experience for this role. You will be rejected without it." The industry is pure technology. I'm not going to name it, to avoid outing the recruiter, as they may well just be the messenger here. (Please let this be true!) I have been imagining the hiring committee meeting for this absolutely crucial role. The conversation goes like this: "Well John, I think the most important thing is that we limit the number of candidates as much as possible. Tell them we'll reject them if they haven't worked in our industry." "Yes Dave, you're right. The worst thing that could happen to us is having ideas brought in from outside. It would disrupt the way we do things. And we don't have time to train them!" (Stereotypes intentional). Evolutionarily, when populations dwindle, species die out, because they can't react to outside challenges quickly enough due to limited diversity. Recruiters - what is your response to clients insisting that they limit the talent pool? Do you try to educate them about the downsides?

4

3 Comments

I think many people in the software industry make the mistake of viewing tech debt like a loan in deferral. They decide to add to their debt assuming there is no short term cost, but one day they will have to start paying it down (or declare bankruptcy with a huge rewrite). A more accurate analogy would compare your tech debt to credit card debt. You immediately start paying for this debt. The minimum payment would barely chip away at the interest accruing. You pay that cost in your project with every feature. The tech debt you add today makes the feature you add tomorrow more difficult. Every work item you take on without addressing the debt will be more difficult, and will likely add to the debt itself. With both analogies, a common end result is crippling debt that grinds your progress to a halt. However, the former analogy assumes that you are making quick progress, when that simply isn't the case. "The only way to go fast, is to go well." - Robert C. Martin

14

I wonder this SRS documentation for a project I made years before can make the cut to get a job as a Software Requirement Analyst.

3

6 weeks. Well, technically a little under but who's counting? That's how long we had to create this MVP. 8 developers, 1 leader; a group of people who had never worked with React Native before. All voluntarily working on this project. We did it. We met our MVP goals we established and created a mobile app with a fully functioning front and back end. I could not be more proud of the work we did. You can check out the source code here: https://lnkd.in/gM_WrVWS A huge thank you to Aaryan Das, Christine Hoang, Ryan Furrer, Acir Rudson, Christopher Cluney, Dina Rocio V., Prescott Lawani, and our fabulous leader Yoo Jin (Yoon) Bae for being so great to work with. Each one of these individuals are incredibly driven, hard workers. I encourage you to connect with them all as I believe they will do great things. Another big thank you goes to the leadership of Dallas Software Developers Group for organizing these cohorts. Everything they do is volunteer-driven and, in addition to creating cohorts, they organize talks and networking meetups. If you are in the DFW area you should definitely attend. For those not local, you can always attend online! #mobile #tech #softwaredevelpment #softwareengineering #frontend #backend #technology #programing #stem #engineering #professionaldevelopment

22

1 Comment

15 years ago I contributed 2 chapters to Clean Code(https://a.co/d/5guLEzq), both related to threading. A second edition is coming out, and it occurs to me that while I don't do much direct threaded/parallel programming anymore, many issues around parallel execution still occur in systems where the stack "takes care" of all those details. Here's a collection of recent examples. This is a draft of a personal blog. The second version will go on the Industrial Logic, Inc. website. The final version will likely be added as an update for the 2nd Edition of Clean Code. Comments welcome, enjoy! https://lnkd.in/gWCUkK6V

9