25+ yr Java/JS dev
Linux novice - running Ubuntu (no windows/mac)

  • 0 Posts
  • 102 Comments
Joined 1 year ago
cake
Cake day: October 14th, 2024

help-circle
  • To each their own I suppose. By which I mean maybe the author enjoys different parts of coding than you do. Trying to wrangle AI into writing something decent is generally an exercise in frustration for me. But I enjoy architecting and figuring out how to define units of work that are small and self-contained enough to get AI to understand.

    I’ve been mulling over what kinds of architectural changes might make it easier for AI to be able to contribute. That’s a puzzle I find interesting in the same way I enjoy other programming problems.


  • My experience with this is over a couple of decades old at this point. So I don’t know that any of it is relevant or useful.

    At the time I was certified in Lotus Notes development and administration. It was a bit of a niche, but it was used lots of places. I created a business to do business under.

    There are websites that deal with corp to corp contract work. So you can find work that way. There was also a specialist independent sales person who worked with IBM customers (Lotus Notes was an IBM brand at the time) who offered to be my sales branch. I never made enough money to hire him. Maybe I should’ve, but I was afraid I wouldn’t be able to get leads and it would be a waste of money.

    I worked with small and medium businesses so there was some word of mouth business from managers knowing one another and recommending me. I tried to go to user group events and meet managers and contractors that way. Having a good relationship and recommending each other for various things is another way of getting business. You could also find some c2c opportunities in other places like dice.com.

    Ultimately, I was not cut out for sales or business ownership. I lasted the better part of a year. During that year I got unemployment from being laid off from my last job but I didn’t pay myself a regular wage from my company — maybe that wasn’t strictly legal, I don’t know, but the money wasn’t coming in regularly enough to pay myself any kind of regular wage. Anyway, I got away with it so whatever.

    I had a couple of good months and a lot of shit months. Between unemployment to help smooth the lows and the business I was able to bring in, I was able to pay for a very shitty house for my family and food. We did have to sell a car. I didn’t plan for it, I just got laid off and walked out the door with 2 weeks of severance and a list of customers I’d been working with.

    I took the next job offer that came along. But if you don’t hate the relationship building and sales work and negotiation, and you have some savings set aside to weather lean months, and stick with it for a few years, you could probably do better than I did. Or maybe it’s all different now anyway. Probably a lot more Twitter and self promotion.


  • You can also use the OpenAPI generator to turn a well-formed Swagger document into code. I’ve used it before. I didn’t hate it.

    The generated controllers have a lot of boilerplate (I want to say 5 classes per controller), but it does guarantee the code is in sync with the documentation.

    That being said, fuck manually maintaining swagger documents. It’s the worst of all possible works.


  • I tuned my usage up once I realized it is universal punctuation. I used to be unfamiliar with it and agonize over which punctuation was best for a given sentence. Can’t decide between a comma, semi-colon, comma clause, parenthetical, or what-not — just use an emdash and don’t fucking worry about it.

    I’m pretty sure I haven’t been accused of being an LLM. Despite my lazy command of the emdash and comfortability with multisyllabic and archaic words, I think LLMs come across as insufferable bores and I don’t think I do that — not to that degree, anyway.


  • I’ve been a developer for thirty years. This is mostly nothing new. I’ve been ranting about the next quarter mentality since the early 00’s. Cool shit does get built, but it’s mostly hacky stuff that proves its value and then must be turned into the real product it pretended to be.

    I’m much closer to the deliver management side of things (at least that’s what my timesheets say) and it’s still someone who has only thought about happy path stuff deciding and selling (Tia customer or to upper management) how long a project should take before there are even people to build it.

    I’m ramping up a project now to replace an existing hacky React solution with a BFF/orchestration service with a Salesforce front end. It’s been scooped at 4 months since I was hired on 5 months ago. Wednesday we had a meeting to the effect that it was only scoped as a dumb proxy to rebuild the same janky solution in SF that we have in React. Except in none of the planning meetings did that ever come up. So I’ve been architecting an orchestration layer and the customer is only expecting to pay for dumb proxies. I wonder how this project is going to go…

    That being said, I’m not hating the job. It’s always been this way. I’ve always had to fight with my managers to eek out decent products while working with my team on what can be compromised and removed from MPV in the how the customer will see the value and give it more phases of development to achieve the original vision. I even have a common refrain for my customers: “I want to make you happy. If my company can turn a profit from that, that’s between you and them.”


  • MagicShel@lemmy.ziptoProgramming@programming.devThe Cult of Clean Code
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    1 month ago

    That’s not my observation. I could flip it around and accuse the author of defending massive if/else chains because my experience is that anything that needs more than a handful of lines of code is either a complex mapper or a nightmare of failed Boolean algebra.

    That doesn’t mean the bad code I’ve seen is OP’s fault. It means there’s a lot of shit programmers and adopting a particular style doesn’t fix it.


  • I think this author has some points, but this is attacking the wrong thing.

    Clean code is not the source of the problems described. If you see similar code and try to extract a common abstraction without further consideration, congrats, you’re thinking like a junior developer, and that’s not Clean Code’s fault, to pull one example.



  • The thing I wish managers understood better is the more exposure a thing has, the more time needs to be spent making sure it’s done right. Spend all the time to architect and get your public API right. One you have consumers, is extremely painful to orchestrate a change if you’ve some something wrong, which will lead to all kinds of tech debt under the hood.

    Then focus on making sure your internal public interfaces are good. By the time you get down to class private implementation I almost don’t care how it’s written as long as it passes tests. (Hopefully I don’t have to say there are a lot of things to care about but they generally are easy to change if you’ve done something wrong.)

    I’m not against agile, but it’s worth pointing out that it encourages the exact opposite — get this piece of functionality working and figure out how to jam in new functionality in a later step. You can’t architect good solutions only looking 2 weeks ahead.


  • Without human feedback

    I’ve identified the problem.

    code that solves the immediate problem but tends to accumulate “design debt” over time

    If by immediate you mean “this prompt” and by over time you mean “fifteen minutes from now,” yes. AI requires human input to build anything durable or valuable.

    The problem isn’t in the coding, but the understanding of the context coding happens in. Code has to be secure. It has to be maintainable. It has to be extensible. It has to solve a business need. It generally should contribute to the long-term vision. It exists within an environment of competing and cross-cutting interests. It has to align with priorities.

    Writing code is a very human endeavor. Solving one business need with 1k lines of code is easy. Doing it within an enterprise that exists beyond just that one need is not.




  • Without considering any other security measures:

    • The client authenticates with the identity provider and receives a signed JWT
    • When the request hits the API Gateway, the gateway checks the signature with the auth service to make sure it hasn’t been tampered with (whether this is internal or external — imagine if one of your servers was compromised, you still don’t want it to be able to forge a JWT with any rights beyond what the service is supposed to have)
    • If the JWT is valid, the gateway forwards the request to the service and the service can trust it without validation (I think. We haven’t gotten to this part yet.)
    • Requests with invalid JWTs are dropped
    • The API Gateway can also handle refresh tokens invisibly.
    • A compromised API gateway obviously could then forge JWTs so if you want you can have each service check signatures on their own, but the advantage of the gateway is that you have a single point of vulnerability to harden rather than trust each service developer to correctly validate the token on their own.

    So you can write the validation part once. I happen to be tech lead on a project to write this mechanism, so it’s pretty fresh in my head.


  • Closest I’ve actually used is Kotlin, but honestly I’d rather use functional paradigms within Java instead.

    I’ve watched a lot of videos on Haskell and Scala, and I think understanding what they are doing and why can only make you a better programmer.

    I use the Java functional package all the time. Understanding how to compose functions and define the input type and output type (either of which could be functions) is sort of awakening. Programming by side effect like with a method void doStuffWith(Foo foo) stands out as red flag if you are familiar with FP, but evidently it looks perfectly fine to someone exclusively familiar with OOP.

    That all being said, I don’t think FP is clearly superior. If you go all in, I suspect you’ll find yourself running into familiar problems wrapped in unfamiliar shapes. I think a very happy medium is to define data classes with only getters and setters instead of rich objects. Business logic can then be moved out to some handler, controller, or operand classes that operate on interfaces which the data objects implement.

    Mostly, FP forces you to think about some hard things and deliberately implement them instead of seeing what the default behavior is and fighting it when you don’t want it.


  • Agreed. I’m a technical lead at a startup. You know that guy in Office Space whose job it is to basically ferry messages between the engineers and the customer? I feel like that is my job. I attend meetings and pass along messages because they are in a different time zone.

    I:

    • try to convince other teams they’ve done something wrong and they need to fix it based on analysis already done by my team
    • preside over meetings where everyone summarizes and agrees upon root cause analysis that is already done by people on our teams
    • babysit the change management process
    • hound people for updates on things they are putting off
    • have meetings with my developers where they ask me for a decision, then correct me when I’m wrong
    • monitor the error queue and figure out what is wrong and fix it

    Some of it is because I’m relatively new, but mostly my job is filling in for my boss in meetings because he’s spread so thin so he can focus on strategic stuff. I feel like my job is just to have 30 years of experience so people take things seriously when I say them. There are people who will ignore a request if it comes from my team, but are super helpful when I ask. There is clearly value to me being here, but I had envisioned something different with mentoring and doling out technical wisdom like “this doesn’t adhere to SOLID principles” or “the best practice here is to do this.”

    The thing I’ve spent the most time doing developing a system where all the little shit I’m responsible for doesn’t fall through the cracks — mine or someone else’s.


  • I think there is a problem with overloading the term API gateway. That’s really an orchestration service that might often live behind the gateway itself. In fact in some architectures each of those service calls would go through their own API gateway, if they serve both clients and services.

    I agree with the idea and have used this architecture multiple times, but calling it an API gateway (which, to be fair, is exactly what I called it the first time I proposed it in design meetings) is going to confuse folks who are already working on cloud architecture.




  • I agree, but I didn’t have the vacation days. I had just enough for the driving day and I think 5 or 6 days for an anniversary vacation in April.

    What shocked me was there was hardly any discernible lightening of the schedule. I expected the week to be pretty light, but I wound up in 8+ hours worth of meetings and deployments every day except Christmas Day. I was given half of Christmas Eve off, but I’d already put in 8 hours by then anyway.


  • I always feel like I lose the trail. I barely ever even take lunch. I recently moved to a tech lead role and I barely have time to look at actual code. I still feel like taking time off is hard because I have to keep constant track of everything or I will completely lose the thread of everything that’s going on.

    I did get Friday off to drive back home from a working vacation. It felt great. The vacation was stressful as hell because I had family stuff and work stuff intermingled. I literally was in my car fixing an issue with a deployment one minute, boarding an airboat to look at alligators the next, and an hour later I’m in a forgettable meeting in the back seat of the car as someone else drives home.

    It wasn’t ideal but the vacation was booked before I had to change jobs and I went from being forced to take that week off to having to cover for 80% of my team. I’m definitely getting too old for this shit, but I enjoy it.