Kevin Allen

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

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

🔥 One of the hardest parts of software development? Managing the unknowns. Earlier this week at Des Moines Web Geeks, we highlighted a powerful approach to tackle uncertainty in projects: Spike Stories. 🔍 Just like Frodo and the Fellowship faced choices between the treacherous Misty Mountains or the perilous Mines of Moria, in development, we face choices with technical unknowns that can derail progress if we’re not careful. Spike stories are your best ally to uncover and burn down those risks early on. Rather than waiting until it’s too late to face those “Balrogs” in your codebase, take the time upfront to explore, experiment, and determine the best path forward. By tackling the unknowns head-on, you can avoid nasty surprises down the road. #SoftwareDevelopment #TechTalk #RiskManagement #LordOfTheRings

12

The development cycle https://lnkd.in/ggh5NTfh Posted on October 15, 2024 how to clean up code. run your code to make sure it works while (work_to_do){ make a small change test it commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review How to add a new feature run your code make sure it works while (work_to_do){ write a small test while (test doesn’t pass){ make a small change test it } commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review

2

My gut tells me that people would prioritize critical flaws before low/medium severity, but new research proves that idea is wrong! Check out this counterintuitive research that will help you manage risk more effectively. #riskmanagement #cybersecurity

1

Automate your build & test with GitHub Actions they said. It'll be easy they said... That was 90 minutes of head scratching, mild cursing, and reinforcement of my belief that somebody other than me needs to be responsible for DevOps matters on any project I'm on. I do NOT have the right mind for this kind of work, and I get frustrated WAY too easily. The workflow is actually working now, but it was a SLOG to get there, and it was failing for (to me,) a stupid, stupid reason. Windows doesn't care if your directory and file names are cased differently from the way they're expressed in the solution or project files. Linux, on the other hand, loses its open source little mind. //TODO: Add another coding standard to the list, and find a way to lint this stuff, hopefully in an automated fashion. See y'all tomorrow. - #thatDeveloperDad #figuredItOut #liveCoding #liveBuilding

6

10 Comments

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

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

4

I find it fascinating that "Site Reliability Engineer" is a title with so much flexibility. In particular, many companies roll a lot of DevOps and Cloud into SRE if they don't have dedicated teams, but regardless you're dealing with some aspects of those as part of the job.

7

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

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

45

2 Comments

Posts that ATTEMPT to classify Software Developers get it wrong ALL THE TIME. Here's why... There is no 'customer focused engineer' or '10x ninja'. There are only two types: 1. Developers with no side projects. 2. Developers with unfinished side projects.

3

1 Comment

"Curiosity over tenure" -- use quality telemetry in your traces to make debugging accessible. Empower curious folks to debug, not just the most tenured person on the team/company. Metrics are great... they're cheap, enable high data retention, but they're coarse... too coarse to understand what's happening in your system. If you're solely reliant on metrics, you'll need lots of intuition and tenure to understand what's going on in the system. "Oh... it's the cache" says the hero on the team peering over a graph, and doing some inaccessible pattern matching. It looks cool, but it's not scalable. Adding lots of telemetry to your traces ensures anyone with a curious mind can understand what's going on in your system.

3

An RPG leveling tree for Engineering Managers 🧝🏻‍♀️ You can also check out the SWE and DevOps leveling trees in my previous posts. TPM and QA coming soon.

4

2 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

Over the weekend, I recorded my talk from THAT Conference and uploaded it to YouTube. It's called "Frontend Techniques in the Realm of Hyrule with React" and is a beginner-friendly dive into React hooks and dynamic content loading. The video includes a link to the live demo & slides, and the GitHub repo so you can check out the code yourself! The repo is a work in progress, so please bear with me as I make tweaks and additions to ensure it's useful!

22

1 Comment

There are two types of mid-level software developers out there: First: Those teaching and sharing how to handle thousands or millions of transactions per second (100K tps). Second: Those avidly watching and reading about how to handle thousands or millions of transactions per second. Meanwhile, both are working on systems that barely handle 10 transactions per second on a good day. #ScalableSystem

13

1 Comment

If you think that keeping track of tools in software development is daunting, you're focusing on the wrong thing. Technologies keep changing, but requirements rarely do. Take version control, for example: we had SCCS in the 1970s, RCS in the '80s, SVN in the early 2000s, and Git and Mercurial after 2005. Yet the core requirement for version control remains the same. The same goes for CI/CD pipelines: CruiseControl in the early 2000s, Jenkins in 2005, then Travis and CircleCI. The need for automation hasn't changed. Infrastructure as code? We had CFEngine in the '90s, then Puppet in the mid-2000s, followed by Chef, Ansible, and now Terraform and CloudFormation. But the fundamental requirement is still the same. So, don't be scared. Focus on understanding the requirements and needs. The rest is just finding the tool that works best for you and reading the documentation.

42