This is a hard lesson for many later in life and why social safety nets are so important for everyone.
1,645 karma · joined May 12, 2014
ian0@dafr.ink
This is a hard lesson for many later in life and why social safety nets are so important for everyone.
- The bigger the change is the harder it is to effectively migrate dependant users/systems/apps
- The bigger the scope is the harder it is to maintain feature parity with the old version through the development window
- The less researched the rationale for the change to users/systems/apps is the more likelihood it will cause them problems
- If you mess up the implementation you are doomed
Hence the best practice to introduce incremental well researched changes to actively used systems in a systematic way.
With a web redesign, there is uncertainty in the way users will respond of course. But tbh ive seen APis with far more unpredictable responses :P
A easy tip for this is to set every meeting to 30 mins but keep the next 30 mins free. Sometimes people worry that they did something wrong when a long meeting is cut short. Works for most meetings not just 1-1s.
- "Business Pundit. “25 Best Places to Network""
- "Undercover recruiter. “Why Employee Referrals are the Best Source of Hire”
.. and a bunch of corporate blogs.
Not saying you cant do the rest. Failing faster will be better than any productivity tips - it will reduce the period where your splitting between day-job & startup. As if the latter is successful you'll need to ditch the former pretty quickly.
Did the reverse with some regulatory documents too, asking it to summarise in vernacular then asking specific questions to better wrap my head around the docs. I wouldn't trust it fully for this of course, more like a supplementary learning aid.
I keep hitting limits with context size though. Eg. When coding it becomes cumbersome once your project hits a certain complexity. You have to carefully construct prompts to get useful outputs. Being able to add the entire source code into a prompt to have more contextual responses would really increase utility.
Its a relatively small data point, but I do think its milk-able. For example for product managers without experience, finding out whether they have actively thought about how things are built the way they are or tend to be unnaturally frustrated by bad design they encounter in life is a relatively solid indicator of whether they will be succesfull.
Its just one indicator though, your will still get false-positives and false-negatives.
If its a big B and you need credentials, you'll need to get that first. You can do it by looking and sounding professional, bringing in advisors who add some weight, getting an intro from the CEO or owner (you'd be surprised how many will pay it forward). If its a small B just wander around and say hello.
People generally want to help people who are making things that help them. And your not getting anywhere without understanding your user so you'll need to talk to them, emphasise. A lot of the earliest discussions will be more around you figuring out exactly how your product will help them.
The prompting took around 3 mins, was in english and the outputted contract was in Indonesian by request. Not a replacement for a lawyer, but it does a great job at boilerplate.
The world changing is the one thing thats constant! When I went to college computer science saw so few students the entrance points were the lowest in the university, they nearly shut it down due to low class sizes. And the subsequent tech revolution was an still amazingly tame and uneventful period compared to the previous decades of social upheaval. Hell even improvements in tech right now are probably less mind blowing than most of the industrial revolution.
Knowledge hasn't changed due to recent events, it doesn't become cheaper or more expensive. You never had to be smart, its just the smart thing to do as it makes filling the bottom part of mazlows hierarchy of needs a lot easier for us humans.
So do what you wanna do and challenge yourself in a nice way. If your sensible get into a career that provides and doesn't bring you down, then do a passion on the side. If you wanna go all-in on painting or acting or indie game design go for it - just realise its gonna be tough.
I will say that the psychological positive of having financial stability >35 cant be overstated. But in saying that Ive rarely met a person who regretted what they did in their 20s, unless is was working all the time.
Hell even the stereotypical hedonistic lifestyle provides value. From that friend who gets you out of the house to do something, the life and soul of the party who makes everyones night brighter, your friend the uber-optimist who encourages you when your down.
I have yet to see a codebase that someone wouldn't re-write given the chance and what makes these companies succesfull is rarely their code.
An effective strategy for dealing with this in an organisation is to move quick and minimise damage. When the shit hits the fan and this starts causing problems, its usually not because a person didnt do any work, but because they did crap work that burdened others. This is especially difficult in engineering. You can identify this and get them off the line quickly, then take the time to figure out whats happening and assist them back on track.
The development of a culture that doesn't incentive people to hoard power helps, the last thing you want is a person performing badly to be in some critical role. People should be able to back down / step up depending on their current "phase"
You can imagine the fastest implementation of the loop is a single dev who knows their customers inside out and talks to them every day, has a flair for product design and works on a youthful and well architected code-base in a language they know extremely well.
In real life speed and quality of the loop are slowed down by:
1. The complexity of your organisations. Even in small companies once the engineer is out of earshot of the customer you rely on "Chinese Whispers" in the form of management, sales, product management, UI/UX, design guys etc. Its not due to incompetence, its just a very hard organisational problem whose solution depends on your company & market.
2. The existing complexity of your product. Products & underlying systems can be architected badly. This can make even trivial things difficult. It could be because of a lack of design knowledge (symptom: too many unused features), lack of systems knowledge (symptom: changing the colour on a website takes a day) or just a complex domain (eg tax accounting, financial services, crms etc)
I think you can trace back most other things (picking the wrong frameworks/languages, badly designed features, poor reliability, time taken with overhead like scrum & needless documentation etc) from the above two.
These guys know about coconut island because they were out on their boat looking for it. Thats the hard part and how you derisk ideas. Understanding your users and market, figuring out how to execute well through trial and error and graft. (And some luck)
Theres crickets are on the insights to their users, what they know about their market, true. This is why its hard to copycat innovative companies. They know their users and the practicalities of running their particular type of business better than others. The ideas in the linked threads are easy to understand, you could interview their users, read a FAQ to see how it works.
I know the "insights" & "ideas" may seem like the same thing, but they are not. Ideas are second order, once you have the insight, you try various ideas to hone in on something that works. Ideas are lovely - easy, simple to understand. Thats why people flock to them. Insights are usually hard earned. Thats why the meme is incredibly helpful - ie forget your divine inspiration get out there and pick up a shovel.
Ideas are trivial. Follow a person around for 24 hours looking at them doing their job and you will have a dozen. Read a bunch of business books and analyse an old vertical you'll have a dozen. Hell ask chatGPT and you'll have a million.
As others have pointed out, whats seemingly missing from your mix is talking to people. If you talk to be people, they will give you problems, then you go about trying to solve them. Along the way you will have ideas on how to do this, most will not work, some will. The way you mitigate the failure risk is by understanding your users, the market better.