>In my experience reducing features is better to begin with.
This is right approach. Lean. If you don’t have PMF, reduce your features until you find it. Pivot. Maybe pivot again. Eventually you’ll find a market to serve. Just don’t fall into the sunken cost fallacy. Time box your market exploration.
As a freelance back-end developer with various co-founding experience this question speaks to me. I think it's all a matter of perspective.
Looking at it from a development perspective the two can mean the same thing: we pivot and so we need to add new features.
However, in my experience the key is to look at pivoting from a non-development perspective. As mentioned in parent comments you pivot to find a product market fit. That entails finding your audience and the problem you're solving for them. Those questions do not require a product, but a human understanding. Questions like 'is it actually a problem they need solving, or a slight convenience?' and 'how are they solving their problem without my product?'.
By pivoting quickly in that space you don't get bogged down by technical issues or challenges that don't even matter, and the real solution might be a week's worth of time.
Pivoting involves picking a different problem to solve. Or who to solve it for. Or rarely, a radically different way to solve it (usually involving starting anew).
Features and other product work is tweaking on the solution side, assuming there is nothing wrong with the chosen problem.
This is the job most of the time, especially at large corporations. You’re mostly fixing legacy decisions and trying to patch together solutions to current problems (instead of fixing tomorrow’s problems). Hang in there.
"Hang in there" implies that the situation is going to improve. It won't. You end up ratcheting your title and pay upwards until you find yourself in the position of doing nothing useful all day for an amount of money that precludes switching to another career without a drastic pay cut. And you're probably hitting your mid-life crisis zenith right around this time too.
"Boo hoo" I know, but it is its own little Dante's Inferno.
Learning comes from focus and repetition. Talent comes from knowing which skill to use. Using AI effectively is a talent. Some of us embrace learning new skills while others hold onto the past. AI is here to stay, sorry. You can either learn to adapt to it or you can slowly die.
The argument that AI is bad and anyone who uses it ends up in a tangled mess is only your perspective and your experience. I’m way more productive using AI to help me than I ever was before. Yes, I proofread the result. Yes, I can discern a good response from a bad one.
AI isn’t a replacement for knowing how to code, but it can be an extremely valuable teacher to those orgs that lack proper training.
Any company that has the position that AI is bad, and lacks proper training and incentives for those that want to learn new skills, isn’t a company I ever want to work for.
If I had a dime for every web framework... We need better desktop api's. It's hard enough having to abstract nuances of linux/unix vs osx and the like. A better, more robust, desktop framework is needed (and no, not just another web framework on top of it because UI is hard).
Less Electron's, more OpenGL's - Less XML and more Swing (just not swing, plz).
Sure, but learn from why the Electrons of the world are winning. It’s because browsers are already what you would get after reinventing the wheel all the way to its logical conclusion— a highly customizable, generic application runner. Let’s not throw that away and make an Nth new thing. HTML/CSS/JS are good enough abstractions with great implementations, and it’s easy to build applications against this. Portability is already solved too. Yes, we can do better than shipping each application with an embedded web browser executable, there are huge jumps being made all the time with native web view frameworks. Personally, I think the ship has sailed on making the “perfect” framework, let’s pick the one that’s already winning and make it the best we can.
Electron/web still has the glaring issue of its primitives being, well, too primitive. They’re great for documents and lighter “web 2.0” apps but have a long way to go for the purposes of replacing full fat desktop UI frameworks.
This is actually a big factor in why web apps have the perception of being bloated. Basic widgets being missing means that everybody and their dog has their own custom implementations, nearly all of which are somewhat slapdash in nature due to speed of implementation being prioritized over quality. They never meaningfully improve either since there’s little sharing of efforts, with everybody instead preferring to reinvent wheels for themselves.
If the platform provided a more robust set of widgets, much of these problems would go away since devs would be using those instead either as-is or with light cosmetic customizations. Over time the browser implementations would get better and all users would benefit with more performant, less buggy apps.
This is what I've been saying for a long time. HTML remains too primitive in its support for rich UI apps.
The main problem I think is what you have identified: we need sophisticated composable widgets with practical and sensible defaults, that are also really customizable with scoped CSS, built right into the browser. This alone would be the biggest QOL improvement as far as web development goes, in several generations. I really don't know why this is not the highest priority for the W3C
> […] pick the one that’s already winning and make it the best we can.
I agree, it can be much better. Tons of incremental improvements have been made, and should continue being made.
I too would like to see browser close the gap completely, supporting everything needed to build real applications, not hacked together applications that accidentally work. We seem so close…
There was something magical about landing on some random page and being presented with a massive flash loading screen that lasts longer than a minute or a java applet. Find a random link on irc and end up on some black website with an exotic loader was better than Christmas morning for me. The web is so exactly as one would expect now, and it's incredibly boring. Sure, java applets, flash, dhtml, tables and frames were a hodgepodge toolbox, but at least the web was interesting to explore... I feel grateful to have gotten to be a teenager through the 90s actively involved in building web stuff. Not sure if it's just nostalgia and everyone feels this way about their teenage years but the never ending exploration into tech, computers, the web, was enthralling...palm pilots, modems, ram, mp3, irc, wow... even thinking about it today gets me excited for that time.
It’s the closing of the frontier. Pioneers opened up new territory, but now it’s mundane. Bankers, grocers, and town councils have all moved in. Streets have been laid out, fence wire strung, and the railroad has decided how you’ll get from place to place. They’re building a courthouse and a jail downtown. The pioneers’ kids are settled in houses; they don’t know how to dress a deer or pick a spot to sleep rough. The frontier that seemed infinite has come to an end.
This breaks go's readability and explicit nature. No thanks. The author doesn't understand the implications of the proposal. What if the args are in a different order returned? "foo, error" or "error, *foo" ? - I've seen many permutations of this. Being explicit about error handling is actually a good thing.
For clarity: The author is Ian Lance Taylor. He's a principal engineer at Google, on the Golang team, and the 4th largest contributor to the language. The personal attack on him not understanding the implications of the proposal is a bit cringe.
It should be about raising the bar, not lowering it. You’d grow if you weren’t the smartest person in the room. Unfortunately this stance prevents one from seeing that.
Even if I am,
and I’ve been hired multiple times to be the “smartest person in the room” , I want to hire people who can outshine me because that means I can just delegate high level concepts and they can run with it so I can move on the other initiatives.
While doing that was half the reason that I got let go from my last job, I delegated the work I was doing to the person I hired and moved on to a newer initiative that was pulled, I still have no regrets.
I got a chance to put leading an impressive “AI” project on my resume and it helped me get my current much better job.
Before anyone starts groaning , it was a framework to do better intent based bots for online call centers (Amazon Connect and Lex). The perfect use case for it.
Yeah... the overenthusiastic tool bringing up labor intensive ideas for minimal gain just means I can't hit the gym at lunch. Not putting up with that so a meaningless metric can go up by 0.5%.
reply