Identify who you and society views as the masters / what "mastery" is

Immerse yourself in their world and surround yourself with them on a daily basis if possible (where/how they work, where they train, where they hang out, what they do)

Create a super tight, iterative feedback look where you can make measurable improvements daily to your current skills, ideally with a testing or competitive component with scoring system or methodology - trial/error and experiment, but quickly

Debrief after these sessions on how it went, what was improving, what could be better, what feels completely off and difficult. Take appropriate time off to digest what you did and avoid burnout

Supplement with theory, books, video review (if applicable) and studying in addition to training and performing so you become a student in the craft

The goal is to get to a point of exponential acceleration and improvement to get you to mastery quicker by determining the pareto 20% skillsets and field experience ("inputs") that create 80% of the output value to get you to that 95 percentile, and double down on that once you've figured it out (and have validated that from the masters).

I personally think chasing mastery without deep burning passion for the thing is dumb and a waste of time because most top performers are probably 90-95 percentile pseudo-masters anyway and just lucky/well-connected. You might hit a point where the masters possess something you don't and never will, so it's crucial to understand that early (like a physical or genetic trait that you are born with or optimized for idk). Assuming everything above is in place, and you have unlimited $ and time commitment to make it work, I estimate a dedicated and focused 8 hours, every day would probably take 1.5-2 years to get to mastery, but YMMV.

Firstly, I believe people will buy almost anything if it's positioned and marketed to them correctly, so I wouldn't get discouraged if there are similar things out there at this stage. The trick is building and positioning a product with specific features that can withstand the buyer question of "what is my next best alternative" and ultimately choosing you. That, plus good unit economics, is how you build a foundation for a strong business. Most likely you'll overhaul the entire app and pivot 2-4 times before you get a strong product market fit, so be open to change (which is why building the entire thing before validating need is a great way to get your heart broken when it needs to be overhauled).

For Taskwer:

> I didn't listen to it

I'd start there, and introspect as to why you ignored the advice of the experts and experienced people. Validating market need before building anything you intend to sustainably sell is always a good idea. This will help you next time around and help you better understand yourself.

> At the same time, salaries didn't keep up with inflation, and more and more people started to struggle financially.

This is ground zero, the starting point, step one, etc. You think you've identified the problem. Who is struggling, exactly? Are you learning about this from a Business Insider or New Yorker article, or do you actually have a line of sight to a real person in your life this macro economic thing is hitting directly? You need to be able to contact at least one, but ideally 10 people to start, who are "struggling" and need to do odd-jobs or service work to make ends meet. Without them, you don't have a need and subsequently you don't have a service or an app that will go anywhere in its current form. You could perform (or purchase) the services yourself for the time being while you figure out who is more important to market to and how to market to them (my favorite lean solution to the cold start problem), then swap in the other participants in that side of the market over time. This can work really well if done correctly. In every two-sided market place there is a favorite child who is more important to the system and needs more attention, like drivers in Uber or homeowners in Airbnb. You should figure this out early on.

> just like on Kickstarter.

You need to have positioning that supports canned responses / dismissals with real incremental value to answer the inevitable comments like: "oh, so like Kickstarter? LOL" or "This sounds exactly like task rabbit". Ultimately I think you'll need to validate whether this incremental value is strong enough to carve out a niche for yourself and win users from the other solutions.

>Now, I have an MVP, and most of the features have been implemented, but I have no users.

Often times the MVP is a fraction of what you think, and you should spend the other X% of your time on GTM strategy and experimenting. The images on the site show payments support, messaging, scheduling, etc. I'll bet you could have prioritized better around a single core need that is unmet, and built the first feature cheaply. In this context, the value is connecting the right people at the right time, and you could deliver this with a cell phone, G-Suite and a great landing page with a form for email/phone number collection.

My impression is this is a grass roots, neighborly / community-driven idea, which is really cool. It has a feel-good, positive slant that pulls on your heart strings, which I think can help with marketing. The next question I'd ask is: "who is the type of person that would buy this over a Taskrabbit or existing expert solution?". Who wants to feel good about paying for services in addition to being happy the job got done?

I would turn to churches and similar groups, community centers, and leverage your own network to find a key partnership that can give you a pipeline of paying customers who want to feel good about using this type of thing rather than the typical service aggregator. In the future, I'd think about hiring or partnering with someone to round out your weaknesses, like an extroverted, people-oriented person with a large network who will shamelessly market the thing and isn't afraid of rejection, difficult conversations, vulnerability, etc.

The site looks great, and congrats on building something and deploying it to the world. That's hard and not many have done this, and is something to be proud of. Worst case, you have a great portfolio project to show off (maybe when pitching yourself as a technical cofounder on the next thing?) Now, if you get one paying customer and see that $ hit your bank account, that's even harder and you're doing what most people only dream and talk about, which is something to be even more proud of. Stay with it!

Always nice when the startup CEO emails you directly via CRM automation about your unique potential at the company and when you agree to chat he hands you off to the "senior technical recruiter". Always makes me feel extra special :)

I'm picturing energetic and socially conscious "hip" 20-somethings doing a country-wide elementary school tour where the whole school gathers in an auditorium to watch them rap about the dangers of social media.

If it works for cigarettes...

Thinking about myself and what I remember. What worked for cigarettes was, graphic demonstrations of health issues along with lots of real proof. The government and society made it inconvenient to use it everywhere.

I don't they held back, I remember getting shown rotting lungs, the effects of lung cancer, holes in the throat, yellow teeth. Lots of death statistics.

This is your brain on Social Media. sizzle

Hey all, Chris from Upways here. Wanted to share a little bit about the story behind this and why I think its useful. Apologies in advance, this is a long one.

During the pandemic I suffered from some serious burnout from a programming career that took a major toll on my mental health. Being a few years into a new SWE role, going to the office was a great change of scenery and gave my days a pretty good lift and progression that I found I really missed when remote work became the norm. My employer had outstanding resources for support and my managers all were incredible at looking after my needs, but even with all of that I felt that my personal life story apart from my job was fading away. WFH became work in this room, sleep in that one, eat in that one, etc and my headspace was so consistently occupied with details around the products we were building that I had lost track of the big picture in my life, where I’m going, and what I value and aspire to do as an individual and not as an employee in a large organization.

I really needed someone to follow up and check-in on me for my goals in the music industry, and overall just stay on top of the things that had nothing to do with my career, so I started a service called Upways. Upways is essentially a team of accountability partners who provide recurring, structured 15-minute check-in calls (1 to n times a week) to make sure you are staying on top of your personal goals, tasks, and productivity outside of work. We do this by calling you at set times each week and asking a few simple questions about your stated goals: 1) What did you complete? 2) What prevented you from not completing something? 3) What are you going to do doing next? - all tracked by a shared google doc.

I originally started doing the calls myself since I was so familiar with the check-in format from my day job, and I really just wanted to see if I could earn some money by talking on the phone with other people and providing value instead of programming all day. In time I built out a team of socially-skilled professionals who range from social workers to accountability/relationship coaches with the key hiring criteria being dependability and hands-on experience with structuring and supporting concrete life goals. I’m proud to say that as of today, we’ve helped people stay on task to successfully build careers in painting and music production, repair damaged relationships, prepare for exams, launch podcasts, lose 60+ lbs of excess weight, prepare for interviews, get job offers, write novels, start/expand internet and in-person businesses, and perhaps most relevant of all - write cool software that matters to them.

It’s been an incredible experience doing all of this in just less than a year since starting out, and my aim is to share this service with the highly talented, creative and motivated people on HN who could use another person in their corner when they’re pushing forward on goals that seem to only matter to them. If this sounds useful to you, I encourage you to check us out or ask any questions. Happy to answer any on here on HN or chris@upways.co. Thanks!

I'm not a doctor or health professional of any kind.

But my friend showed me a study a while back of turmeric supplementation and how it can be comparable and in some cases more effective than prozac: https://pubmed.ncbi.nlm.nih.gov/23832433/

I started taking 450-900mg daily and noticed an increase in optimistic perspective and seeing "the point" of doing things during rut of burnout after quitting my last job. Just my story. This is not health advice.

Be careful, turmeric can sometimes be adulterated with lead chromate to give it a more vibrant orange color. Make sure you buy from reputable places that test it if supplementing.

Would adding it to food have the same effect?

Personal take/rant/experience:

I fell in love with programming because I didn't give a shit about maintainability, architectural considerations, stressing vulns or holding a pager all night to support a living computer system. I learned how to code and got the degree because of how much fun it was every day as a beginner - growing, learning something new and exciting, feverishly building new things to show my friends and use for myself.

I hate to bring a cloud over this profession but I recently left engineering completely because of my depression and how harmful these ways of thinking can be to a person in the long run: modeling everything an equation/stats model, applying worst case scenario visualization and planning to everything you do, risk analysis and limiting your downside by covering every base, preventing you from going all-in on your dreams and enjoying the reward from the risk. You're basically being paid to be paranoid and to think and act like a computer all the fscking time.

Not everything can or should be quantified, and your value as a person and the relationships you have to others are not math equations or statistical models. The incredible beauty and magic of the human experience exist outside these modes, and can be found in your relationship with people, your feelings and emotions, and the freedom to follow your nose and truly embrace things that are meaningful and fulfilling to you.

I empathize with this. My job is to package analytics and build forecasting models and if the data shows anything less than stellar it becomes super stressful to try and dress it up and contextualize for management. [Proverbially] shooting the messenger is a real phenomenon and no one likes the "actually things are looking bad" guy.

> applying worst case scenario visualization

I recently learned about "thinking traps" (essentially spiraling out of control imagining terrible outcomes) when my pandemic stress hit an all time high.

I learned coping mechanisms and ways to short circuit them (really comes down to awareness), but realized that I get paid to engage in this destructive behavior! We have pre-mortems at work trying to imagine everything that might go wrong; a little of the macabre mixed in with the stress.

I became a professional programmer later in life, and I've been wondering whether or not it has been influencing my behavior and personality in negative ways. I don't remember this paranoid in my previous life.

Try scaling back all forms of social media + notification-based apps and start re-adding them incrementally, one variable at a time, and track how you feel and think in response to each new addition. It takes a while but opens your eyes to the egregious behavior modification taking place on these platforms at scale.

I'm at a point in my life where I only care about major, materially-significant news events that could impact my health/safety and the safety of people I care about. I treat all other content as ignorable, nice-to-have at best.

Being already known by my friends and family to be an "overthinker" and prone to "analysis paralysis", I sometimes wonder why I'm still a SWE. I've slowly started to realize over time that my profession is filled with overthinking and over-engineering, and that our interview process can even select for it. IMO its hard to be the person that aces the technical interview gauntlet then walks out of the building and turns the analytical skills off.

Many interview processes seem to favor how well a candidate can enumerate edge cases and problem spaces over effective risk assessment and cost management. They're both important to evaluate but often in practice the dumb solution is what my team ends up using because can be more maintainable, cheaper to build, easier to reason about, etc. Today my aim is to get my requirements, write as few lines of quality code in as short of a time as possible, test it, ship it and be done.

Narrow focus and the ability to scope things down to what exactly what matters helps a lot. I defeat over-analysis by meditation, intentional dumbness/willful ignorance, and flow state.

As someone who's been programming for years, one of my biggest complaints in software is over-engineering. It's so universally prevalent, I literally expect to get downvoted for even making this comment. I strongly advocate for simplicity in software implementation, allowing for maintainability and flexibility... the cleanest solution that reaches the goal and doesn't lock us too far into a narrow approach that may be difficult to deviate from. Sometimes that's not realistic, but it's actually feasible a lot more than people seem to believe.

It's a weird term, "over engineering". Think about over-engineering a bridge. What does it look like? Huge and bulky, way too expensive, able to hold much more weight than it should, lots of walkways and access points and design features that nobody really wants? But wait: "any fool can build a bridge that doesn't fall down. It takes an engineer to build a bridge that just barely doesn't fall down." The whole point of engineering is to figure out exactly what the bridge needs to do and make it do only that. So the "over-engineered" bridge is actually under-engineered -- they haven't thought enough about the actual problem. So too is most code that is called "over-engineered" -- it's far more common that people haven't though enough about the problem than that they've over-thought it.

When I say "over-engineering" I mean stuff like this: https://github.com/MarkSFrancis/enterprise-fizz-buzz Building a whole ton of stuff, just to do something fairly trivial.

In this example, it's black and white obviously over engineered. The reality is, in an application of moderate complexity, whether or not it is indeed over-engineered is a far more subjective calculation.

E.g., >90% of engineers would agree enterprise-fizz-buzz is over-engineered.

But perhaps ~50% of engineers agree my SaaS app is over-engineered.

Just to be very clear, that application is intended as a joke. (just in case)

> he whole point of engineering is to figure out exactly what the bridge needs to do and make it do only that. So the "over-engineered" bridge is actually under-engineered -- they haven't thought enough about the actual problem. So too is most code that is called "over-engineered" -- it's far more common that people haven't though enough about the problem than that they've over-thought it.

It is different in the physical world where materials are a big factor and engineering will definitely not make free use of them. There are inefficiencies here and there but they're largely reduced. In the digital world of programming accidental and intentional complexity often slips through without anybody noticing and that is for many reasons. It's a relatively new field and is still quite inefficient. I worked in many places whose codebases are a giant maze designed with no clear architecture and sometimes I suspect this complicated mess of intentional moat building engineering.

I think that in a way that view is like the entry level engineer's lie. It makes it seem like the engineer is there to make shoddy things, always a hair's breadth from failing.

What an engineer is actually there for is to run the numbers and predict behavior without having to go through the mess or expense of doing it any more than absolutely necessary. To plum the depths of our collective technical knowhow to drive a project that makes all the right tradeoffs.

It's not about making a bridge that can hold a semi out of matchsticks and bubblegum. It's about knowing it won't work without having to do it to find out.

I like to call it "poor engineering" and there are many forms of poor engineering I've seen. Following the analogy... painting the bottom of the bridge in same color as the terrain. Then repainting because there were color differences.

Spending time and money looking for lighter materials even when the bridge is designed to support a lot more weight than traditional time tested materials. Justification : "Maybe cars will get heavier, and bigger saving 3 pounds is a good pursuit"

But people will hate your suckless bridge and instead will use a more feature rich bridge with more bells and whistles. https://stroustrup.com/P0977-remember-the-vasa.pdf

I like to believe that experience will eventually drive people towards using scientific parsimony when creating solutions to engineering problems.

I don't think over-engineering is the only problem: shiny-new. Shiny-new syndrome wherein the typically junior programmer cannot help but jump from one new thing to the next, advocating that some new system must use the new tech that they recently discovered. While the enthusiasm is ok, working with people like this can be a drag.

Another problem: we are facebook too! In the sense that small companies heartily believe that they actually have problems at the scale of a company like facebook (or will ever get to that level). Again, hearing someone say, "We should do xyz because Netflix does it!" makes me want to give up on this profession.

> Another problem: we are facebook too! In the sense that small companies heartily believe that they actually have problems at the scale of a company like facebook (or will ever get to that level).

Precisely! It's tiresome how many people setup Kubernetes for a network of 2-6 computers.

I was with you once, but last year's I got tired when people set up networks of 2-6 computers with daemons that run in a wildly different ways, and it's not clear how to fix their failures, where configs and metrics and logs are. I'd honestly prefer overengineered kubernetes setup nkw, only for some more standard way of doing things between projects.

That's a false dichotomy though. Having a standard way of doing things between projects does not require running a complex distributed system with dozens of pieces all engaged in constant chatter. It's a testament to the failings of our profession that we apparently cannot agree on a sane baseline toolset less complicated than Kubernetes.

Infrastructure as code is much easier to handle than full backups of the configuration of your mutable machines, even for 1 machine.

The only problem it has (and why I don't use stuff like kubernetes at home) is that the configuration formats aren't stable and thus require a lot of ongoing maintenance.

"over-engineering" is a fuzzy term though. For someone, using a third-party service to handle users auth flow is a time saver, and building the whole flow themselves would be over-engineered. For another, using a third-party service for auth would be adding layers of complexity on top of a simple db request, and would thus be considered over-engineered.

Largely agree, but I've found distilling complex requirements down to a simple implementation takes effort, and sometimes longer than the more circuitous route.

A coarse rule of thumb from a few decades of my own experience in software development is that version 1 will be quick, dirty and (in retrospect) naive. Version 2 will improve it with what you learned the first time around. And version 3 tends to be the clean, solid, polished winner. I've learned to expect and encourage refactoring to arrive at this point.

"I would have written a shorter letter, but I did not have the time."

In my experience, you often start with a somewhat over engineered solution. Then you take the (long) process of really understanding it and slowly distill it down. This is true for a new feature and also the whole codebase.

Yeah, that's a great point. The final code I submit is often 2/3 the size of what I initially got running (perhaps less, even). I'm always happy to see a code review that is removing more code than it's adding, haha :) I like to use the phrase "measure twice, cut once" in regards to shipping code. Take the time to pare it down to the truly essential functionality, trimming away extraneous stuff that complicates things and may even be premature optimization. It's certainly a skill that takes time to improve at, haha

Wholeheartedly agree. The best system is no system at all - problem is it doesn't really satisfy any requirements. Anything added beyond that is extra room where fragility creeps in & the tradeoff shouldn't ever be taken lightly.

Reminds me this comment: https://news.ycombinator.com/item?id=19977678

There are other coping mechanisms you can use, although some of them are arguably worse than procrastination (eg overengineering).

In my opinion over-engineering is a symptom of not enough thinking. Complex, over engineered solutions don't happen because a problem is too well understood, they happen because a problem is not understood well enough.

This is based on the assumption that more thinking == better understanding.

Recently I've been interviewing and assessing technical tests regularly.

We have this one technical coding challenge. Most of the submissions are 1000+ LOC and quite heavily engineered. One submission though was 300 LOC, runs 3x as quick as everyone elses and is the only one to get 100% in our acceptance tests. The author was very self-deprecating about it - describing it as a quickly cobbled together submission.

I'm nearly 40 and find I over analyze the design of everything. Which is great when I'm architecting a high level software feature, but when I get to coding I'm almost at analysis paralysis over every, damn detail. I miss that sense of flow.

Generally speaking, the less complicated something is, the less weird combinations of states one can find themselves in.

Now you probably shouldn‘t code golf either, but KISS works as an operating principle for a reason.

> the ability to scope things down to what exactly what matters

In the last few years, I started shifting my focus from what variety of cases to handle with an elaborate solution, to what possible cases I might be blocking with a simple solution. Gratuitous YAGNI was an important intermediate step in that process. It might not be very FAANG-friendly (or it might not scale to four-digits-engineers regardless of brand), but both in terms of real life performance and peer feedback, it's yielded very good results.

While the first is prone to becoming a bottomless pit of SWE-self-pleasuring; the latter is actually very useful in coming up with something that's cheap, easy and maintainable, but still flexible enough -- which doesn't necessarily mean extensible! Ease-of-refactoring is another flavor of flexibility, and that's where I found this kind of thinking beating YAGNI alone.

One actual drawback I see is that it makes DRY difficult to achieve, but the more people I work with, the more I'm becoming disillusioned with that anyway. It's such an overly adaptable dogma to generate work that is often pointless, and becomes harmful so easily. I think we found so much comfort in "don't type the same thing twice" (though I still try to keep it to 3) that we don't stop to think about "don't maintain the same information twice" anymore. But this is 3AM rambling, so I'll stop here.

> I sometimes wonder why I'm still a SWE. I've slowly started to realize over time that my profession is filled with overthinking and over-engineering

You've already seen how to be a better SWE than most.

Now you just have to execute.

"if it's dumb and it works, it's not dumb"

"You can't argue with success."