I was charged with felony unauthorized access of a government computer years ago for an even stupider reason. Nobody should underestimate the state's willingness to prosecute over anything.
I'm a technical lead, and I often tell my teammates exactly how I want them to implement something. I am not looking over their shoulders at every line of code, but I will tell them plainly that I want an interface, a concrete implementation of the interface that is up to them, and a configuration option for substituting a different concrete type.
I don't do this because I don't trust them but because I have different requirements. What matters most to them is completing their work items according to specifications. What matters more to me is long-term maintainability of our projects for the rest of the team.
Some of them have the long-term needs in mind. Some of them just don't think that way. I try not to make them feel like their work can't be trusted or like my demands are arbitrary. I think they are more receptive to my demands when I can at least provide context for them. That seems absolutely necessary to me.
I ask myself all the time whether I'm insisting on too much control. I appreciate you asking of yourself, "Is this my ego?" It can definitely go both ways.
> I often tell my teammates exactly how I want them to implement something.
Ugh. I recently found myself working with one of those people. What a horrid experience. We waste days trying to reverse engineer out of him what the business problem actually is, and then, once we finally figure that out, even more going over all the things he failed to consider.
Software isn't the technical Olympics. It sole purpose in life is to solve human problems. You must work from understanding the human problems. "This is how we are going to do it" obscures all of the information that is necessary to write good software. I have no qualms about pushing back to ensure that we start from the right place, but it is so draining when it happens over and over. Building software doesn't have to be so stupid.
Don't be that guy.
> I ask myself all the time whether I'm insisting on too much control.
No. You're not. Someone has to wrangle those who are not providing positive contributions (without a forceful hand). But your job is to figure out why they are not providing positive contributions and solve for that problem, not to continually tell them how to do their job. You are no longer in a technical role. "Lead" means you are now in a people role, solving people problems not suitable to be solved with tech.
If you'd rather be a software developer, consider doing that job instead.
The first time my director asked me if I'd ever heard of DevOps, I said, "Sure, doing two jobs for one paycheck." I'm a software developer, buddy. I write the programs. Leave me out of running them.
Here's the extent of my interest: I take my understanding of your use case and specifications, then I write source code that tries to generate as few instructions to suit your needs as possible while still being comprehensible to the next maintainer.
The app should write records to a database? Fine. Here's where you configure the connection. The app in production is slow because the database server is weak? Not my problem, talk to your DBA.
The app should expose an HTTP endpoint for liveness probes? Fine. It's served from the path you specified. Your reused it for an external outage check, and that's reporting the service is down because the route timed out due to your ops team screwing up the reverse proxy? Literally not my problem, I could not care less.
Allow me to politely pick apart the "Not my problem, talk to your DBA" comment from the perspective of someone who's worn every IT hat there is.
Okay, so, what is the DBA to do? Double the server capacity to "see if that helps"?
It didn't, and now the opex of the single most expensive cloud server is 2x what it was and is starting to dwarf everything else... combined.
Maybe it's "just" a bad query. Which one? Under what circumstances? Is it supposed to be doing that much work because that's what the app needs, or is it an error that it's sucking down a gigabyte of data every few minutes?
How is the DBA to know what the usecases are?
The best tools that solve these runtime performance are modern APM tools like Azure App Insights, Open Telemetry, or the like.
Some of these products can be injected into precompiled apps using "codeless attach" methods, and this works... okay at best.
So SysOps takes your code, layers on an APM, sees a long list of potential issues... and the developers "don't care" because they think that this is a SysOps thing.
But if the developer takes an interest and is an involved party, then they can integrate the APM software development kit, "enrich" the logged data, log user names, internal business metadata, etc... They log on to the APM web portal and investigate how their app is running in production, with real-world users instead of synthetic tests, with real data, with "noisy neighbours", and all that.
Now if Bob's queries are slowing down the entire platform, it's a trivial matter to track this down and fix Bob's custom report SQL query that is sucking down SELECT * FROM "MassiveReportView" and killing the entire server.
Troubleshooting, performance, security, etc... are all end-to-end things. Nobody can work in isolation and expect a good end result.
DBAs don't necessarily need telemetry in an app to diagnose an issue with the app's behavior. They can run a trace and see some SELECT is running a thousand times a second and deduce that it's being called in a loop over the result set of an earlier query. And they'd be right to say hey, this is an app issue, open a ticket with the developer.
If you put that responsibility on the developer--meaning you expect the dev to diagnose an issue that they introduced in the first place--what kind of result do you think you're going to get?
Layering these demands takes away from the overall quality of the application in my experience. You want an app developer to learn all about Prometheus so the app can have an endpoint with all these custom metrics, okay, and you want structured logging and expect the dev to learn how to use Kibana effectively? All that's a huge cognitive burden that eats a slice of the same pie (their brains) as domain knowledge, language & runtime knowledge, etc.
Get maybe one app developer to specialize, get maybe one app developer to cross-train with ops or monitoring even. But leave most of us out of it.
When you flip that expectation of developer involvement in operations, it exposes how unreasonable that arrangement is. Hey, DBA, the app is sucking up resources. Why don't you crack open an IDE and write a patch for it? What do you mean you don't know Go, what do you mean you don't use Git? Every DBA should know how to attach a debugger to a remote process, shouldn't they?
It's just exploitative. Or at least that's been my experience, so there's my bias.
Which CalDigit dock? I have the TS3 Plus. Using its Ethernet port and Thunderbolt 3 to my laptop, I'm getting the expected 1,000 Mbps connection on my home network. Do you have a different model or maybe a defective unit?
After going through the same pains as the author of the piece, I switched to CalDigit as well. No concerns or problems for me on a Mac for about a year. I had one that went bad, but I bought it off Ebay so I figured that might be more my fault (and it might not even be bad, I think I set it up wrong with the wrong Thunderbolt cable (too long for the power needed).
Clearly the US needs a constitutional amendment to preserve the right to keep and bear AI tools. Then we can arm the victims of AI tools with their own AI tools, for self-defense. If we're lucky, AI will send its AI thoughts and AI prayers in carefully calculated quantities.
Add the buzzword when you see a story you don't like. Or settle with it filtering 90% of the AI content and just don't click on whatever remains, I doubt you expect the top story to be interesting to you 100% of the time.
Our brain decodes info based on context and extrapolation
This submission we're commenting on could be about filtering out any data, not just AI stuff. Politics, crypto, AI etc. Or more minute like "Trump" "fracking" "bitcoin" etc.
In any of these scenarios, with a tool designed to filter out content based on limited context, when would you ever be perfectly satisfied?
would you like AI to help you build the perfect context-filter model?
And certainly in our anti-politics filter we’d want to include the filtering of stories that promote the extreme political position that tech is somehow detached from politics! (Especially Silicon Valley startup tech that owes so much to the local politics and economy of California).
Which is to say, filtering politics out is absurd, one person’s extreme politics is another’s default view of the universe.
Isn't it enough to bury yourself under the rock? - you want the fact of your having done so concealed from you also? But what about the fact of wanting that?
...Yes? This is how this tool is coded. Machines do what one codes them to do, not what one wants them to do. If you're interested in making a more intelligent tool you can do it. This tool does exactly what @simonw says it does.
A tool was offered that can accomplish what you want, with a very small amount of added effort on your part.
No, you do not have to "stay up to date on AI stories"—if you see one, add the keyword to the list and move on. There are not as many buzzwords as you seem to be implying, anyways.
If you are dissatisfied, you are welcome to build your own intelligent version (but I am not sure this will be straightforward without the use of AI).
This is a good way to introduce regressions, particularly if you don't have the QA resources to do full regression testing each release and lack automated test coverage.
I don't say this to scold you, but I think most of us should keep in mind that even simple code changes incur risk and add testing requirements.
reply