He looks like a fucking hot head. I grew up with The Butterfly Effect, but this dude is just trying to juice his celebrity into something he either doesn't have the capability to understand - to its full extent - either his acting days are over and he just wants to make some profit, being the puppet of someone that knows better. Anyway, Ashton isn't dumb - he's just trying to be alive, doing all that it takes. Just fucking human nature man
> Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion.
Thanks for your awesome reply! Means a lot to me! Let me dive along! To make this discussion more interesting from the start, I'm going to say that we managed to raise $2M with an MVP written in 4 months, and now I have to rewrite everything because the business team pivoted 180 degrees. Bear with me a little.
> Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
The only failure I feel is that I haven't really managed to employ the right people for the right job. This forces me to take care of everything - really, like I have to refactor Typescript interfaces or CSS for other people, which are trivial things but time consuming. On one hand, I have to move fast and deliver features as a team, but on the other hand, I have to teach people how to properly do their job.
> For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
The expression 'building cool rock-solid code' might've been just me venting my frustration - it's not that hard to do a good job it if you know what you're doing. But you're 100% right: I'm wasting resources if I don't implement the business needs in a timely manner. I actually managed to pull that off before raising the money.
But I'm also aware that difficult problems have more than ordinary solutions. I took care of our infra, from Proxmox, docker, Google Cloud, Jira, Confluence, Cloudflare, to Slack, emails, Jira, Confluence and others. The business team just says: "we could've employed anyone to do that".... really ....
> Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Actually you're right and this is the reality. IMO, I see the grand scheme of things, where I know what "should" be done, so we could attain 100% autonomy and be able to scale without coding anymore, whereas the business team needs some features NOW, forcing me to do shortcuts. This is why I'm pushing to build a roadmap, but it's obvious we cannot do it right now.
> Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
We have 10k users, we have the market fit, we have the funding. The only problem is that I built everything for a specific business case, and now I have to abstract it to support the previous business case, plus new others, which are completely different. It's like building a new product from scratch. And my pain is that we could've thought about it from the start - this would've allowed me to abstract some of business logic.
> Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.
Exactly, no plan is going to be perfect, and we're constantly iterating over it, but we didn't allowed ourselves to start this damn plan from the beginning. We thought: "let's do it, see what happens. Wow, it worked! Let's do even more now, and be backwards compatible"
> What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.
EXACTLY! We had poor product and domain knowledge - basically we built our way without having a good sense for them. The code is flexible enough: monorepo with apps and libs sliced and combined in separate packages, while trying to follow 12-factor-app methodology as much as I could.
> Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.
This is where the friction comes inside the team. I want to plan as best I can do it, and then just execute. Talking about my experience, I was employed in a German project where people actually took their time to plan thoroughly, at a point where they knew exactly what people they needed and almost the exact buget for the whole thing. And it was a joy to code and do your thing. In retrospective, looking at this German team, they really knew their tools and craft.
> Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
I've been using solutions like Supabase, Hasura, n8n, Prisma, just to move things faster. IMO, it all boils down to understanding the product and domain. Then the table schemas, data structures, interfaces, services, etc, will start fitting into place. In my case, they still do, partially, but I could've done a better job at abstracting them from the first place, rather than patching or rewriting shit at this point. I'm lazy.
My takeaway, even it might sound childish or wishful thinking, is this:
1. I won't start a startup with non-techincal founders anymore
2. I won't touch a single line of code if I don't understand 100% the product and the domains
3. I will strive to employ only the right people for the job and I will document everything from the start, so the onboarding curve would be low
4. I will enforce best practices, standards and internal protocols when it comes to writing, testing and deploying code.
5. I don't want to think when I read code; a quick glimpse is what it takes: looks good, passes tests => OK
6. I want to be able to delegate as much as I can, without fearing that quality might suffer
7. I should follow my guts and speak louder when the business team wants the Pyramid of Giza - at a point looks like a challenge that I accept, but then it translates into lost nights for myself.
I might be biased, I know I'm not that experienced yet, I know there's no such thing as a perfect world, but I can strive to achieve that. Maybe I'm just venting - nonetheless, it's still possible to build a product without having a gun pointing at your head.
In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"
As a dev i've always known my hunch when it comes to compromises. Never let the business team ruin your experience building cool rock-solid code. I'd rather resign than to compromise anymore. I know there should be a sweet spot between "perfect" and "working". Even a junior can pull-off a "working" app. But when it starts to scale, all those hasty bad decisions will bite your ass. Never skip planning, plan as long as you need. Nowadays i start coding only after i have 100% visibility into what i'm building: diagrams, dependency graph, schemas, types and data structures, documentation, user flows, everything. As the say goes: if i have 24h to chop a tree, i'd sharpen my axe 23h. And we haven't yet taken into account infrastructure, devops, ci/cd, security, releases, logging, and all sorts of tooling. I need around 2 months just for initial planning, setting everything up and laying out the codebase structure.
Kadena is probably the only proof of work blockchain that's infinitely scalable, has low gas fees, even introduces the concept of gas stations. They just announced a $100M fund for development.
My only problem here is that some people seem happy about this - and they have the best intentions. My opinion is that you shouldn't forget about the people behind these kind of operations. They clearly seem elitist, and tech&gov history showed us that these initiatives are mainly rigged for purposes unknown. "For the people", right ?
You're right but never forget how the world, systems and people work. Even if you're an absolute rationalist, these ideas will keep flying in the realm of abstract. In the real world, idealists are starving. Cheers for your thought exercise, but real life will prove you that you're wasting breath. Just enjoy
Exactly. Seems like the US is pulling a PR stunt, most likely being a contraption of a whatever-congressman-and-his-friends with a plan to get richer, trapping nice kids into a yummy trap
Because it gives unexperienced and young people the status they think they seek - also connections which are inevitable - while they will be ultimately transformed into the people of the deep state. And hey, that's fine - even the deep state needs new people right ?
You are too romantic about it. Read the other comments. This is such an excellent idea, but it's a closed sourced system wrapped into sweet package. I don't doubt the output of it, but c'man man, we know better right ?
Being so selective means that only those with the highest credentials get approved - and we all know how these credentials can be harvestered: 90% nepotism and elitism, while only 10% skill. Those 10% will be the brains, while the 90% will bring the network onto which these solutions will be promoted