151–160 of 401 posts
As much as it's true that a novice will generally use AI to build a sloppy mess, I've also had success unsloppifying through some careful prompting.
The chasm between "Software Developer" and "Software Engineer" is getting wider. Articles like this and the comments under it give away who is an Engineer and who is just a coder.
This is such a low value article lol I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and un…
However... NONE were "the 10x developer" who built up a huge mess. Which a team and I had to spend months and months cleaning up after.
Earlier quoted context omitted.
You are not alone. I was in this exact same position at MSFT and I put in my resignation. I am an L63 but the work I was doing, was something an L60-L61 could do and I frequently felt I was in one of those Bullshit jobs (courtesy of David Graeber). I was paid handsomely but once the sign on stock ran out, I saw that I was staying in the job just for security. I felt like one of those Hooli engineers who were sunbathi…
> I am an L63 but the work I was doing, was something an L60-L61 could do Maybe the problem is imagining that you need sixty three levels of granularity to describe experience or to establish superiority over sixty two categories of "lesser" engineers?
The point I made was that as an SSE (L63), there’s a certain amount of scope and autonomy that is expected neither of which I was getting and hence I resigned. I am not trying to bully or denigrate anyone junior.
The levelling system specifies the output and the characteristics of the output expected out of an engineer, that’s it. Whether I believe in it or not is beside the point, I was in the system so I did believe it otherwise progressing through my career would have been impossible.
Earlier quoted context omitted.
> Just getting the code to run on your laptop took a week. This one surprised me. Claude Code in the CLI has made standing up an app and debugging whatever random dependencies or docker BS a dream compared to the before times, when you'd have to learn the architecture while simultaneously troubleshooting whatever isn't working on your machine
And in the before times, you learned a lot and walked away with knowledge on the deps needed, connections, .env secrets, and cleaned it all up and documented it so the next dev would have an easier time doing it.
I'm right there with you, but this last sentence concerned me a bit.
In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can still get art and paintings that someone poured weeks of work into, but most people buy their wall-art and chachkas at HomeGoods.
The main difference is the disposability assumption, and software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are. This mindset doesn't align well with software that must continue to operate in order to support some process. A disposable countdown app, sure, throw it away, but anything built around long running business processes should not be treated in that way.
I have concerns that focusing on software craftsmenship frames the issue as "boutique and bougie and unneccessarily expensive" vs "what I need for my usage", instead of "maintable and trustworthy" vs "disposable".
[0] Is that an initiative that benefits large model providers like OpenAI/Anthropic? maybe, but that's not my point here.
As much as it's true that a novice will generally use AI to build a sloppy mess, I've also had success unsloppifying through some careful prompting.
Any tips on how you unsloppify things? Are you using things like claude.md/copilot.md (or similar) to guide better, do you have specific types of prompts that you run, or do you adjust your code review practices in some way to more efficiently review lots of slop code? One of my particular complaints is how code-gen LLMs tend to re-create the same code over and over again. Case in point, a use-case where a team name…
Once the LLM tells me "Okay, it's done, everything works" I always as it to do a thorough review, I tell it to split up the work among sub-agents with each one taking on a specific responsibility (look for code smells, look for bad architecture, review the data access model, DUPLICATE CODE, testability and unit testing, etc.)
After a certain number of revisions and reviews you'll come to accept the shortcomings it comes back. Usually there will be specific design decisions you made that the LLM keeps bringing up, once the review only brings that up and maybe some other minor issues it's time to move on.
I don't overly rely on markdown files and directions. I don't rely on tooling around it either. I just don't trust the LLM when it says "all done", tests pass, and deployment works. I make it to multiple reviews and iterations even when it thinks it's done.
I've said it before, I'll say it again, I'm convinced LLMs will be the thing to convince software engineers to get it together and create a licensing board. Somebody wake me up when the ABET SWE PE is back.
Earlier quoted context omitted.
Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame. I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a pr…
It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code. If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.