I did do web work for a long time, but I grew tired of it, so these days I just do contract work on legacy systems and platform modernizations. Some of those systems may have a web UX, some do not. But the work is more about refactoring architectures to get off brittle tech that nobody knows anymore, and move on to tech stacks where you can actually find talent to run it.
It is a different experience to be sure - I work on stuff that nobody likes and where most people are surprised it still exists. And my goals tend to be about shutting down, not growing. I succeed with every server we kill, every product we turn off, every customer we get rid of.
So you used the existing version as a base, then iterated on it? If so, that is a sketchy way to do it. Start from scratch and you are golden, but copy/paste/iterate isn't cool.
No. Just Stop. The prior monthly post is still the #1 on the "ask" page, and even monthly it is a high noise ratio. We don't need it faster, we certainly don't need people posting their own thread just to pimp their personal project.
Putting the version number in the domain is a fairly strong "I'm just going for quick cash grab from a wrapper app" signal, if I've ever seen one. As is the blog link with no entries. The utter lack of any information on who is behind this, what they are actually running, or anything at all about what this really is that is different than using any existing platform.
> But what if we've been wrong about what matters?
Still wrong, though. Does the final product solve the problem it set out to solve? Because that is what matters. Specs and code are both tools to achieve that. So while this article is a good start... if you think that AI has changed what matters, not only were you wrong about it before, but you still are.
The idea of just re-building a whole app via LLMs when changes are needed is cute. But then you are also going to have a whole new set of bugs and UX changes. For anything non-trivial, documentation will be wrong, training will be wrong, people's experience will shift and complaints will ensue. Sure-fire way to increase churn, which is a bad thing.
I'm working on hand-building mugs. Throwing clay around in a studio, etc.
But I'm also thinking about it as a product manager based on my tech experience. Looking at what people like in mugs, creating templates to exactly size the mugs to people's preferences, creating re-usable molds to put repeatable components together, and taking detailed notes on exactly what I am doing in-studio to create a repeatable, reliable process to create a product that will sell.
It is going poorly so far, but each iteration gets better, so hopefully I have everything down before I end up with 100+ unsellable mugs in my kitchen.
That is just how being a PM goes. You need to take all those inputs and synthesize a vision that meets as many needs as possible, without delegating control to the stakeholders.
The most important thing to learn is how to say "No", and that saying "No" should be the default answer.
You add features when multiple stakeholders agree they are needed, not when one new guy shows up in a meeting. You listen deeply to them all and understand why they are asking for things, and devise a solutions that solves their underlying problem - do not just take their requests at face value and implement them. Then you get to surprise them in UAT, when instead of them telling you that you failed to solve their problems, they tell you: "Wow, not what we asked for, but this is even better than what we had thought of."
It is your job to be the expert in what the customers and stakeholders need, so take all those pain points and embrace them as opportunities to learn more deeply what the correct product to build actually is.
It is also your job to set the priority, so there is no situation where everything is priority #1. People can tell you their own opinions on what is most important to them, but the actual priority is set by you.
When building up something small and new, sure, checking security in each route is quick and easy. But a time will come where your security, roles, and whatnot have evolved to the point that new features and roles would mean you need to go update every route. Aside from the tedium to do so, it introduces more changes which means more potential for mistakes. That is when middleware is better.
When you do get to that point, don't hard-code checks on whether the current user has the exact roles for that specific route. Instead, get more creative. Every app will have different needs, but I like to do all the setup for the auth checks when they first login, cache an array of their allowed routes on the server, and then you just check whether the cache has the current route on each request. (Yes, and clear that cache if their access changes mid-session.)
Doing so is not much code, performs well at scale, and you never have to touch the routes themselves when refactoring security, you just need to tweak that setup function.
My experience is that different people have different roles. Those focused on the tech are probably focusing in their own space. Those focused on marketing are probably trying to kickstart discussions online. So when you are looking at what discussions you see, which group do you think you are really looking at?
I agree. i have seen marketing and sales ( mostly just talking about competition). But I think if we care talking more about our product with just a sense of where competition is that should be better.Idk
It is a different experience to be sure - I work on stuff that nobody likes and where most people are surprised it still exists. And my goals tend to be about shutting down, not growing. I succeed with every server we kill, every product we turn off, every customer we get rid of.
reply