Jonathan McCormick

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 only valid measurement of code quality is # of WTFs/minute" I can't remember if he's the origin, but I got that from Robert Martin's clean code. And honestly looking back on my career it is true. But it does not only apply to SWE, I think it applies to Engineering or better yet symmetry in general. You see, the problem with bad code or a bad design, is that based on what you know to be right (and hopefully you are indeed right) what you are seeing is asymmetrical. Examples: An API fails to implement the intuitive use case. Or Drastically changing the behavior of an SUT does not trigger a failing test. Or Someone writes code that only expects the happy path.... what if the remote item you are trying to interact with is unavailable? In all this, it is probably worth noting that Symmetrical doesn't necessarily mean "Correct", it just means it makes sense to you. So make sure you are indeed correct (probably by fact checking and having empirical data)

1

1 Comment

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.

3

I'm in the middle of a bathroom remodel. It's led me to reflect on a special role software engineers should be eager to fill ✨ I have to answer a bunch of questions about my bathroom. How large will it be? What tile? What kind of vanity? Which size bathtub? If everything was free, what would I choose? Whatever I like best! Fine Italian tile 😍, custom-built mahogany furniture, large cast-iron bathtub, etc. What if I knew everything cost something, but I had no idea how much until I bought it (no returns)? This is a bad situation because I have no idea how much of my budget I'm using up with any given decision. I might accidentally spend half my budget on tile and have to settle for a cheap vanity, when the vanity was actually the most important thing to me. 🤦‍♂️ So, who is your best friend during a remodel? The guy who attaches the price tags. The business people at your company are the ones in charge of a remodel... a software product remodel. They need good information to make good decisions. That's where software engineers come in. We attach the price tag to every feature request. Sure, it's not a perfect price tag. Sometimes we have to say, "let me check some stuff and get back to you on that." Sometimes the price ends up being higher or lower than what was on the tag. That happens during bathroom remodels, too. 🤷‍♂️ But it sure is better than nothing. Why? Because with no price tags, everyone is frustrated. 😠 With no price tags the business people are making blind decisions and are frustrated when the engineering budget is gone with half the features done. With no price tags, engineers feel like the world is being asked of them. "I'm doing my best, they are being unrealistic!" As engineers, we should be thrilled at the opportunity to attach the price tags. Don't worry — the business people will love it, too, because the answer will never again be "we can't do that because blah blah blah." It will be "sure, we can do that. Just be sure to check the price tag." 🤝

11

3 Comments

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

The number of characters that need to change to fix a bug is inversely proportional to the amount of time it takes to find the bug.

3

1 Comment

There is no doubt in this fact considering the better features we have experienced when using Playwright like async awaits, no promises, checks retry, better debug, single API, complement dev workflows, using websocket protocol for faster execution, browser context for isolated test execution, supports cross domain like in case of SSO redirection, parallel execution...

5

One of the most common things I hear when talking to devs is "product wants me to do x, y, and z, but their changes look so bad" or "their changes make no sense". Devs: don't forget, you are all part of the team, and all responsible in part for shipping a great product. You can push back on these "requirements" to contribute to a better product. Through legal teams, UI/UX teams, artists, product, and others, devs are the "last line of defense". Devs are the ones implementing the actual thing. As such, if product wants a button to be used as a text box for styling reasons, it's sensible to push back on that. You're the last line of defense; say no—it's your imperative to do so as part of a high-functioning team. In the screenshot from a website I recently visited (actual UI text replaced), the super long button that falls off the screen (that's not supposed to function as a text box/callout) could have been prevented by a dev pushing back against the wants of UI/UX/product.

20

1 Comment

“Why doesn’t anyone want to hire me?” - Entry Level Developer This is a question I often hear and I’d like to share a story about “A” reason why this happens. A long time ago I worked with a company where they hired a developer straight from college. It was their first development job and it was a great opportunity to learn skills they haven’t had before. The manager spent an incredible amount of time training this person to get them up to speed. After one year passed this employee demanded more money, of course why wouldn’t they? The company was not willing to budge on their salary so they left. It cost alot of money for companies to onboard employees and train them, so more times than not companies want to bring in someone who is going to add value quickly. In order to combat this problem, especially if you are an entry level developer, is you need a way to show case how much value you are going to bring into the company you are applying to. You can do this by taking part in open source code, coding for local business, getting involved with like minded folks in your community by attending meetups and coding together. Whatever you decide to do find a way to code that doesn’t involve another tutorial but solves a real world problem. Let’s go! 🔥

363

54 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.

4

Three reasons I love doing DEFTs! We just wrapped up another DEFT for another great client. What's a DEFT you ask? It's our "Developer Experience Friction Audit Tool". Put simply, it's a holistic evaluation of your #DX / developer journey, from the perspective of your potential developer customer. Here's three reasons why I love performing DEFTS for our clients: 1. I get to meet great people who really care about their organization's developer journey / developer experience. 2. From new technologies and APIs, to frameworks and new types of learning resources, I get to learn new things all the time. Each project not only broadens my scope of experience, but allows me to see what's driving the pulse behind today's top companies and technologies. 3. DX audits are a chance to make a real difference for our clients and their developers. From identifying what's working, to areas of opportunity, it's rewarding when we uncover things our client's may have never thought about before. Want to learn more about DEFTs? Check out: https://lnkd.in/g3tNEneu

4

3 Comments

Unit testing user interfaces makes some people uncomfortable. When it comes to Blazor, we're able to unit test the UI with a package called bUnit. This gives us the ability to inspect the elements at a particular state without needing to have a headless (or full on) browser running. Next time you want to skip writing unit tests for your UI, just remember... you CAN do it! 👇Check out the comments for the link to the article!👇 ---- 📨 Sign up for my email newsletter! 🗣️ Share with your network! #blazor #aspnet #dotnet #testing

13

3 Comments

The Software Development market is heating up again. It is wild the difference between a cold and a hot software dev market. For Senior+ it's always a little warm, but last couple years have been unreasonably cold. However, I would say now we are red hot again. Here's the deal though... evaluate the offers for what they are. Are they trying to rehire after laying off 1000s of their developers and are now desperately behind on deliverables? Or are they a promising startup with a lack of technical debt and a great work culture who just now received their long sought after funding round. Give it 2 months I'd bet it's red hot 🥵... if the Fed backs down the interest rate a little before the end of the year.

3

Is this valid TypeScript? Why or why not? I 💖 type safety. I recently gave an engineering talk on it at Stay AI and this line of code helps explains the differences between values and types in TypeScript quite succinctly.

7

These are great tips for an junior dev. Especially the suggestion to become the "go-to person" in a particular topic. It's a great way to become an elevated contributor on a team. https://lnkd.in/gqUZSn39

5

Programming 101, Ask for help. When I was a young developer, my manager told me “if you are trying to solve a problem, give yourself time limit of 1 hour and if you do not find a solution in that time, ask for help”. That helped me heaps in my career. Do not spend hours on a problem before asking for help. Do not wait for a seasoned developer to barge into your life because you look a bit in distress. That will not happen, not many of us can read clues like that. Ask for help.

3

YOU ARE NOT A "FULLSTACK DEVELOPER" Back in the 90s, I learned Sutron Data Language on a flight to Arizona. It wasn't like any language I had seen before, but by the next day I was writing code that would eventually be used to manage a large dam on the Lower Colorado River. And that was fine, because while I didn't know squat about this cool little language when I boarded the plane, I did know a hell of alot about industrial automation. Nobody cared what IDEs I'd used or what languages I knew. The truth is, the people signing the checks don't care which ones you know either, anymore than I care what kind of hammer a roofer uses to replace my shingles. A "Roofing Hatchet Specialist" makes alot less than a "Hail Damage Remediation Specialist." If someone is fixated on your language experience, you are interviewing at the wrong level. All ANY CEO or owner really cares about, is if you can solve their problem, because you are not a "React Developer", or a "Rust Developer", or a "Fullstack Developer." Stop sending out resumes and start focusing on what domain knowledge you can build that makes you the ONLY PERSON they want to hire. I've never landed a decent job from a resume. Become a problem solver, and that's all ANYONE is really paying for. Read this post and more on my Typeshare Social Blog: https://lnkd.in/dWKKFkdE

104

41 Comments

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

Devs, want one tip for improving your design communication? Add diagrams! I just finished reading a 12-page document describing a distributed-database crash-recovery protocol and there wasn't a single picture! It may all be clear in your head, but describing complex relationships in prose isn't going to get the same level of understanding as if you draw out the relationships as well, especially if there are temporal components. When I was leading EBS, one of my colleagues suggested a rule: that every change proposal had to have at least one diagram or it wouldn't be considered. Now occasionally this meant that a very simple proposal would have a silly diagram just to meet the retirement. However, more often what the proposer thought was a simple explanation wasn't so simple to the readers and the diagram really helped!

97

5 Comments