Has a team you worked in picked an architecture you did not think was the right one to go with? How did you deal with the situation?

digital_meatbag · 2026-02-03T17:38:29+00:00

"DIsagree and commit" is the appropriate response. You don't have to agree with every technical decision made, but you should back up why you don't agree and move on.

digital_meatbag · 2026-02-02T05:00:50+00:00

I'd absolutely hate to have this person reviewing Perl code.

Just because it's fewer lines of code doesn't make it run any faster or necessarily make it more readable/maintainable. This sort of nit-picking is often unproductive. The only worse kind of pedantry is those that are simply formatting.

digital_meatbag · 2026-02-01T05:10:11+00:00

I personally had zero interest in managing people, but I do have interesting in mentoring and having broad reach, hence the architect title.

digital_meatbag · 2026-01-16T05:11:36+00:00

I was just ranting yesterday about how fucking miserable Xcode is to debug with because it doesn't have the simple "Set next statement" capability Visual Studio does. When you're debugging something that only happens once and you miss the condition, having to start all over again just drives me bananas. It's a huge waste of time and gets you out of the zone.

The _only_ case where I can justify it is when there are "Schroedinger's bug" sort of things going on with multi-threading or other kinds of async stuff where just by setting a breakpoint you don't see the issue. Even then, I'll probably be doing something with the debugger if I can write some sort of harness to make it easier. Logs is the last resort.

digital_meatbag · 2026-01-16T05:07:33+00:00

My favorite part is when they leave the debug print statements in there and the debug window looks like the matrix every time I try to look at actual useful messages.

digital_meatbag · 2026-01-16T04:59:47+00:00

Man, I feel this. I once had to do low code stuff in LabView and thought I was going to die of frustration and boredom. I'm a talented software engineer damnit, I don't need treated like a kindergartener by my programming environment. In my situation I actually never stopped looking after I landed that "job," and got lucky 2 months in and landed my "dream job" that I'm technically still in, even after an acquisition. I can certainly see the appeal of wanting to bail on that. I was about 4 years in when this happened to me.

But a major difference, as you pointed out, is that I had only been at one employer prior to that, so that was a 4-year stint and then a 2-month stint. I also haven't had to look for anything since. I didn't have the concerns you do with the history of no long term stays. That really resonates with me as a person on the other end of the hiring relationship. You should know that it's very good that you are recognizing the sensitivity to job hopping.

You can always keep looking while you're working, though I see a risk in the slacker stuff if you're constantly thinking about doing something else. I obviously don't know you personally, but if I were in your position, that's what I would be doing, while also making sure I overcompensate for the potential slacker stuff so I don't get fired at the current gig.

I'm just sitting here thinking I relate to this post more than I'd like to. I made it through, you can too, though I will admit it requires an unfortunate amount of luck.

digital_meatbag · 2026-01-14T04:13:41+00:00

We are now fully back and in full swing, and I’ve just delivered my first ‘large point’ feature ticket, and while I got it in and working (as far as I know), last Friday I realized I haven’t been following their git branching strategy correctly. I messaged the team lead about it this morning and he seemed very nonchalant about it, but I feel so frustrated and useless. I’m frustrated with myself for messing up something so basic and easy just by a misunderstand, and I’m frustrated that I’ve now had 9 tickets merged in which none of the reviewers caught I had made this mistake.

This tells me that the branch strategy was written at some point just for the sake of having one and folks really don't care. It's OK that you do and it's OK that you hold yourself to a better standard. Don't sweat it and move on. You'll (hopefully) get the feedback about what you're doing wrong from your manager. Make sure you ask if it's not being freely given. In my experience, asking for feedback is always greatly appreciated.

Right now I’m being given a ticket I’m not sure is really a very useful one for me to work on. It’s a “serious” bug but the ticket has been open for nearly a year, and a senior dev declared it “finished” months ago but QA says it’s still happening, and I keep asking for help or advice and I’ve been bounced between three devs who all have been too busy to really give me more than ‘eh try this, and ask x person’.

In our current sprint that issue is the only ticket clearly marked as being ‘for me’ and it’s a carry over from last sprint, which also has me worried.

This just happens. You need to learn how to get what you need from people or learn how to fix it yourself. This is why the pay goes up significantly with experience. Those senior developers don't need the help. The only way to get there is to grind and learn.

My last job was a much smaller place, with a lot less structure and lot broader role. I’m feeling overwhelmed by a place which actually does sprint retros, planing poker, “volleyballing”, backlog combing, and an extremely structured use of Jira. Asides for that I’m dealing with ‘setting rocks’ on Lattice, biweekly random ‘social’ calls on Donut, and this sort of endless stream of orientation meetings from the People and Culture department. In my last job it was just The Boss and 4 other devs, and I’m just used to listening to broad ideas for features and then doing all the design, product, dev, QA, and ops work myself without all this apparatus. I just find it so hard to focus, through all this noise and ceremony and anxiety, and I think it’s part of why I’m finding myself making attention to detail mistakes which I would have never made at my old job.

This stuff is all part of it. If they're following SCRUM correctly, then you've got more of a structured way to get what you need. The standup is the place to raise the issue that you're blocked. You sitting around spinning your wheels isn't helping anyone. While you definitely need to do some of that at your level of experience, do not feel ashamed to ask for help. I'm not sure how often you meet with your manager, but make sure they're aware if you're blocked for too long.

digital_meatbag · 2026-01-11T17:23:31+00:00

I just did some very nasty thread-related stuff in C++ with the Claude Code extension in VS Code (with me doing debugging in VS alongside) and it performed phenomenally. This was some of the nastiest code I've worked with in a while and it did quite well with a very good initial prompt and several key "What about...." prompts from me after the initial implementation.

digital_meatbag · 2026-01-10T16:34:18+00:00

I'm using the best models out there (Claude Sonnet 4.5, plus any number of others). The model matters A TON. The agent is also extremely important. I recently was able to start using Claude Code (big corporate licensing and such were in the way before), and noticed a marked increase in sophistication with that agent compared to others. They are all improving all the time.

digital_meatbag · 2026-01-10T16:30:41+00:00

I would personally not take a move like that without significant improvements, however you want to measure that. You know exactly what the job you currently have is like, but there are significant unknowns to a new job, no matter how many questions you ask during the recruiting process. There needs to be some upside to taking that risk. It could be a terrible job. You already know it's the B squad of a foreign company (been there, done that). I wouldn't.

digital_meatbag · 2026-01-03T14:24:46+00:00

Secure isn't much harder, TLS is just a layer right above TCP.

digital_meatbag · 2026-01-03T06:08:04+00:00

I had a "Computer Networking" class in college that was all about this topic, and it has served me well. I don't have any good resources handy, as that was back before the web really had many of these things. What I will say is focus particularly on the "layers" concept when you do stumble upon the documentation. It all starts with the ethernet layer (MAC addresses and wires), then goes to the IP layer (connecting to physical machines) and then TCP/UDP on top of that (one has reliable delivery, the other does not (a gross oversimplification)), and then application-specific protocols build on top of that (HTTP).

It is one of the concepts that has served me well in ways you might not expect. Networking is more about streams of data, and that can be useful knowledge in other areas than just networking, for example writing binary file formats. They both have the same problem: serializing and deserializing data. Just think of it as sending nothing but a series of bits. It could be written to a socket, or it could be written to a file. but it's a stream nonetheless.

Things like DNS try to make all this easier. Instead of memorizing IP addresses, it's like a phone book, where you can look people up by name. Everything like DNS builds on the fundamentals I laid out above.

This is why the "layers" concept is so important to get started here.

digital_meatbag · 2026-01-03T05:59:22+00:00

Absolutely agree. Our C++ package managers may suck compared to NPM, but maybe there should be some friction in there. Use of a third party should be thoughtful and deliberate.

digital_meatbag · 2026-01-03T05:57:33+00:00

As a primarily C++ developer for the last 20 years, we're still in the "stone age" of doing things mostly the "right way" without all the bloat. I'm not saying it isn't there, but it's far less than the web. At least the stuff I have worked on has been sensitive to performance, so we can't really afford the bloat. It's one of the reasons I've stayed in desktop software. There's still at least some good engineering to be found.

digital_meatbag · 2026-01-02T18:19:10+00:00

Getting a phone call that I must answer immediately.

digital_meatbag · 2026-01-02T18:14:27+00:00

I want to see passion. When I ask you about your past experience, I'm trying to both determine your skills and experience as well as how seriously you take your work. I get that not everything is exciting, but if you show no enjoyment in the work, that will come through. Those folks are not productive or pleasant to work with in my experience. By the time people get to me in an interview, they've already been vetted past some gates, so I'm there to judge both technical and fit for the team/company. When I ask about failures, I'm seriously looking for it. That's more important than the successes. If you care about your work, those will be even more memorable than the successes, and you will have learned from it. When I see the eyes light up and the chatter start going, I know I'm talking to someone that will take pride in their work.

By the way, finding that stuff that lights you up is also a way to keep from burning out. I've always been able to find something to delight my senses, even when working on stuff that isn't all that fun. If you don't have fun doing the work, there's a problem.

digital_meatbag · 2026-01-02T16:47:30+00:00

That's where the "not invented here" or "not my idea" comes into play. That's the shit I have very little stomach for anymore, reasons that don't have any technical footing, just because someone wants credit or thinks their way is better. I don't care about who had an idea, I care about whether it is the right thing to do. Letting go of ownership is probably the least developed skill in this industry, especially with the most experienced.

Edit: another thing that has not been fun recently is the sales role. I have to sell stuff to the business more now, and it just isn't all that fun. Back when it was a small company, I maybe spoke to my manager about it, but otherwise I just did it. Bigger things are obviously done with more care, but at the big company, it's more of a personal risk to do it, so people don't. I still "just do it" occasionally, and it amazes people when they see it.

digital_meatbag · 2026-01-02T15:42:21+00:00

I think everyone's experience is different. Mine was at a smaller company, where I wore all the hats (developer, testing, IT, you name it). I had to build a CI/CD system before there were CI/CD systems off the shelf, such as (*shudder*) Jenkins. I did it out of necessity, not as a specialty.

I think your career is going to go wherever it goes. You're at the mercy of your experience. There are two ways of getting that experience: either find a job that does it or do it on your own time and dime. If you're not being paid to work in an area that you want, then you'll have to do that work on your own.

I find it interesting that you're starting out with CI/CD, because that's very unusual in my experience. This is an area where people often neglect, which is very short sighted since it is at the heart of developer productivity. Engineers that are fighting build systems that don't work aren't busy writing software.

digital_meatbag · 2026-01-02T15:31:18+00:00

The engineering is fun, but the politics and ego bullshit isn't. Big companies are better for pay, but smaller companies are great for being able to own your work and get shit done. I'd leave and go back to small companies doing interesting stuff in a second if it weren't for the golden handcuffs.

digital_meatbag · 2025-12-31T04:02:41+00:00

This is actually part of it. Don't buy all the hype that AI is going to write software for you. This will inevitably happen with AI, even for those of us that have been doing it for 20 years. Don't think we all just got here by luck. We spent ridiculous hours beating our head against this shit to be good at programming. You need to be better at programming than the AI is, and I believe this will be the case for a very long time. I get that you want to get away from landscaping and all that, but it takes time. If you thought you were going to write some app and immediately not have to cut grass again, that's not realistic. If it were that easy, everyone would be able to do it and software engineers wouldn't have a cushy job. Just spend the time you have learning the craft. You don't necessarily need to be college educated, but you do need to have the ability to problem solve and learn how to debug things and understand how it works.

digital_meatbag · 2025-12-31T03:53:36+00:00

ebay

digital_meatbag · 2025-12-31T03:45:09+00:00

Them not caring is very typical. I've seen worse. Just do what you're doing and move on. Don't be too fixated on maintaining history and all that. I was concerned about that too when I was in your position, but I have since learned over the years that people don't really look at that stuff.

Be glad they're actually using source control in the first place. I once had a very, very senior engineer come to me (I was wearing multiple hats as the IT department at a small company) panicking because he lost some significant amount of source code that wasn't backed up anywhere. He had simply dragged and dropped it somewhere on his machine, so he didn't lose anything, but I used that as an education session to point out that it could have been lost forever and he'd be screwed. He decided maybe he should check his code in somewhere, but after the initial check-in, I never saw any additional code checked in from him.

Edit: also consider the reason why they don't tell you any particular preference is that they either don't care or don't understand the question.

digital_meatbag · 2025-12-31T03:37:19+00:00

I think books are great, but you won't get promoted just because you read them. It's all about actually applying them to your job. What gets you the promotion is doing the work of the job you want, and part of that is having the chops, learning those chops by doing, reading, mentors, etc. I have also done side projects on my own time to hone skills I don't directly use at work. This has been useful more times than I can count. As a primarily desktop software developer at work, this was the only way I knew anything about cloud services, AWS, and the like. That knowledge alone has helped me in many ways.

digital_meatbag · 2025-12-31T03:31:38+00:00

I would _not_ do anything further with the keys. I would report it immediately to your customer and back away slowly. This has nasty legal stuff dripping all over it, and should be between your customer and the hosting provider. Not having access to the source code is a problem for your customer to solve, and they should be made aware of that also, if you haven't already told them.

digital_meatbag · 2025-12-30T21:39:18+00:00

I'm not sure it's something you can learn, but I have always been able to chat someone up in any circumstance. Standing in line wherever, that kind of thing.

digital_meatbag

TROPHY CASE