Kimberly Wynne

Everyone should take this "ghost engineer" research with a grain of salt. It's not peer reviewed and has *significant* limitations. You also can't position yourself as an expert on code quality or software engineering productivity when your own website's code has automatically detectable bugs that impact accessibility compliance. There's nothing productive about shipping broken code that puts you at a risk for lawsuits. Great reporting here by Jason Koebler on 404 Media: "Are Overemployed ‘Ghost Engineers’ Making Six Figures to Do Nothing?" https://lnkd.in/dhhUH8Av --- Image alternative text (also set on the image): Side by side of the mentioned research project's website and HTML. Two button-looking shapes are outlined with arrows pointing to their respective HTML. It shows that each one is an HTML button with an HTML anchor (or hyperlink) element inside.

17

4 Comments

Hey devs! One of the most common form accessibility issues I see out there is misusing the "for" attribute on the label element. The value of the for attribute should reference the ID of the input field you are labeling. The incorrect use I usually see is instead of an ID you're referencing the name. Name on an input field sets the name/value pair that is sent on submit of the form. If you're trying to connect a label to an input field this way the connection will not be made and there will be no accessible name for the input field. Users will not know what the field is asking for! Even worse, if you had an implicitly connected label/input through wrapping the label an incorrect value for the for attribute on a label will override the actual label! Here's an example: <label for="test"><input id="testID" name="test" type="text"></label> ☝ This will result in an empty accessible name because the "for" attribute value (which is not matching any ID in the document) will override the implicit "content" text pulled in through the parent-child relationship. In this example, remove for="test" from the label to restore the accessible name. Referencing the correct ID of "testID" would work as well, but is redundant here.

27

1 Comment

Peer review is the heart of academic process, and also the heart of software quality. Unfortunately, the incentives for individual contributors tend to make this a non-priority. (I need to write my own code / paper, let's just do the minimum to be social and get back to my stuff.) To be fair, "service" is only weighted at 10% of your annual eval in most institutes. But honestly, it is a very important 10%. The community (or company) won't run without it. I'd like to support Brian's process here for ensuring we do our bit to write good reviews. As for code, so for papers and proposals. (Though sometimes you can't do the Loom bit, because authors are anonymous :) ) P.S. LLMs don't help very much. The best I tried was Claude.ai, and it still got most of the key points wrong.

6

Hire for the person you need 3-6 months after a person fills the role. Or, better yet, the next role. You can teach a specific tool or how you code within a specific programming language. So don't hire for that unless the job is BUILT around that tool. The things you're really looking for propel the person into the next role or into doing more in the current role - and faster. When I see what you've got your applicant tracking systems screening for...it can really make me shake my head. I come from the days before it was all online. From when it was both easier as simpler. I used to place ads in a thing called a newspaper. Yes, really. So the advice comes from then as well. Make every word count on your job description. Put your specifics in the preferred qualifications. Know what you truly care about, and commit to keeping your tech job descriptions relevant to the work and a career path. You'll have to revisit and revise tech job descriptions more frequently than other types of roles. Today's advice - do not filter out people with 10+ years of technical experience who lack a technical degree. Need a hand hiring tech people? I can help.

49

9 Comments

Accessibility Tip of the Day 269: Writing as clearly as possible is called using "plain language". Plain language makes it easier for people to read, understand, and follow information online. This is particularly helpful for any sort of government communication. People need to be able to understand how to do things like apply for a passport, renew their driver's license, or vote. There's even a whole website dedicated to this concept! You can learn more here: https://lnkd.in/gw9H-zBC #accessibility #a11y #accessibilityTipOfTheDay

32

1 Comment

If you've ever had any interest in the prospect of software development but don't know where to start, here's a blog written up on Skillsoft by the very talented Alec Olson detailing a little bit about the overall gig, the tools we use, and what makes us tick. It even features a couple of quotes from yours truly! Thanks again Alec for the opportunity to share some of my experiences. https://lnkd.in/gECfjYen #coding #development #softwaredevelopment #fullstack

11

1 Comment

I've worked on a number of libraries in my career, some open source and some not. One thing I've learned is that it's hard to design good library interfaces! This was stuck in my drafts for a bit and was on the verge of getting too long, so I edited it down and published it. Here's a quick read on the lessons I've learned along the way that might be helpful to folks. #softwareengineering #programming #softwaredesign https://lnkd.in/gFVpPA8F

11

A few controversial things I believe about writing code: 1) Code should be comforting, not just functional. I’m not saying it should be flowery or overcomplicated. I’m just saying it should be easy to read and pleasant to navigate. 2) Comments should be personal. Contrary to popular belief, dry comments are a waste of time. “Initializes variable.” “Checks condition.” “Executes loop.” Generic comments are hard to remember and easily overlooked. 3) Humor belongs in your code. “Most people” keep their code dry and formal. Which leads to… Boring code. Disengaged devs. Missed opportunities for connection. Clearly, what “most people” do doesn’t work. So, add a little personality. 4) Consistent formatting isn’t negotiable. 99% of the time, neglecting formatting is a giant mistake. Instead, Robert Martin’s “Clean Code” framework offers a path to elegance without clutter. Consistent naming conventions. Proper indentation. Thoughtful use of whitespace. 5) Pursuing code efficiency at all costs is a silly goal. Because readability and maintainability often matter more. Code that’s easy to understand is a better pursuit in life. It saves time. It reduces errors. It fosters collaboration. If we all have to spend time there anyway, why not make it nice? In a world of deadlines and conflicting requirements, your code can be a refuge, a place of quiet contemplation. 🪷 Read this post and more on my Typeshare Social Blog: https://lnkd.in/gjZbQJrP

8

I've been quiet for the past few days because I've been studying. I've been a technical writer for two years now, and one question that I've struggled with silently has been, "What's the difference between a tutorial and how-to-guide?". Look, If you've not struggled with this, it's okay, but for the love of God, I just couldn't figure it out. Until last week, that is. So, remember, I just got accepted to the AsyncAPI Initiative mentorship program? While going through their onboarding checklist, I came across the Diátaxis framework for documentation. So I took a look. Now, I always say documentation is beautiful, but this is one of the best things I've read for a long time! Thank you, Daniele Procida—what a gift! If you’re into tech docs, I highly recommend checking it out. Back to my gist. So what's the difference between the two? A tutorial is about learning—it’s a guided path that helps someone understand why certain steps are happening and builds knowledge along the way. On the other hand, a how-to guide is about doing—it’s practical, action-focused, and geared toward achieving a specific task. This wasn't so clear, but what hit the nail on the head was that a reader uses a tutorial while trying to acquire knowledge, while a how-to-guide is used when applying a skill. It's still a bit blurry, so I've spent some time going through some of my work and identifying each of these different types of docs. If you struggle with this, I hope this helps, and If it's still unclear, consider reading the diataxis docs framework! https://diataxis.fr/

38

6 Comments

I’m starting to realize that many of the posts I read about using dev processes that don’t involve branching are responding to the use of “Feature Branching,” long-lived (many days or weeks) branches that don’t get merged til a fairly large feature is complete. I realize that it has been a long time since I worked on a team that did that. I’m sure people do, but moving away from feature branches isn't the challenge in many of the recent teams I’ve worked on. The bigger challenges are: - Being able to merge a change to main within an hour or two after it’s done (clunky Pull request processes) - Being able to have something merge (perhaps on a Task Branch) complete in a day as opposed to 2 or 3 (larger tasks or multi-tasking) - Having to support an older release (code is deployed less than once every few weeks). We could get better and reduce all those times. Maybe many teams struggle with Feature Branch workflows, but I’m guessing many are just trying to make their short branch workflow faster and more effective. That’s the audience I’m looking for when I share my Agile Codeline Patterns work. So, while I agree that Feature Branching is evil (as Thierry de Pauw has written), I still see a benefit to using a short branch workflows--

6

72 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

I've been reading through a textbook I've had on my shelf since college, "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. "Uncle Bob" Martin. Great, easy read, highly recommend. Within the first page I felt seen, understood, and validated in my professional struggles. I want to share a quote from the first chapter that really stuck out to me, regarding attitudes towards messy code and who is to blame for it: "[...] How could this mess be *our* fault? What about the requirements? What about the schedule? What about the stupid managers and useless marketing types? Don't they bear some of the blame? "No. The managers and marketers look to *us* for the information they need to make promises and commitments; and even when they don't look to us, we should not be shy about telling them what we think. "[...] 'But wait!' you say. 'If I don't do what my manager says, I'll be fired.' Probably not. Most managers want the truth, even if they don't act like it. Most managers want good code, even when they are obsessing over the schedule. They may defend the schedule and requirements with passion; but that's their job. It's *your* job to defend the code with equal passion." This is something that I truthfully have struggled with, and still do, in my career. This quote reminded me that *I* am the expert on the code, and I am responsible for it. It's my job to understand how and what effort it takes to get tickets done, yes, but more importantly, what it takes to get it done right. Maintaining a high standard in the code will add time to any given ticket, but will save time over 10, 20, 100 tickets. I must include that caviat when communicating estimates, rather than giving the estimate for the bare minimum for the sake of "saving time" or "getting it done ASAP." My experience at my current position I think exemplifies this. Having taken over a fairly derelict project full of "unclean code," the onus is on me to become the expert on the code regardless of quality, and to be capable of making meaningful additions to the code in reasonable time. However, naturally I was stalled, "wading" as Uncle Bob puts it, for a very long period of time due to the lack of care the project had before I came along. Moving forward while following clean code principles means to clean the existing codebase as I go along, ensure that what I add or modify is clean, and most importantly, include that prerogative in my calculus for work estimation. "The Boy Scouts of America have a simple rule that we can apply to our profession. 'Leave the campground cleaner than you found it'" -Robert "Uncle Bob" Martin, "Clean Code"

2

1 Comment

I see a surge of posts on LinkedIn along the following lines: "I am a better software developer than anyone I know. However, despite this, I keep getting fired (or nobody wants to hire me)." Well, the inconvenient truth is that, if you keep getting fired (or if you are struggling to get hired), you should consider that you may not be as good as you think you are. I am not trying to disparage you. The data in your environment shows that you may be wrong. However, thinking that you are already better than everyone else prevents you from growing to the level where you become attractive to employers or consulting clients. After all, how can you learn anything if you believe that nobody has anything worthy to teach? This is the opposite of impostor syndrome, but it's much worse. While impostor syndrome is unpleasant, it actually motivates people to keep learning. The superiority complex, on the other hand, stops any learning in its tracks. P.S. If you comment on any of my posts with thinly veiled insults and your profile is a combination of you saying how you are better than everyone else and complaints about how you never got any reply back despite sending out 500 resumes, I will not bother engaging in any debates with you. I will block you right away.

58

52 Comments