caprock

I find it's best to just understand the landscape at a big picture level first. Then you only need to follow details when a need arises. It helps relieve the angst.

For example, I understand the landscape of machine learning and the landscape of generative models inside it. I can't rattle of each model or it's nuances, but I can research that when it's really needed.

Or on the UI side I roughly know about react frameworks and such. But not more. I don't do much UI work so it's fine to just mentally slot all the posts about react, next.js, typescript, etc in that vague box and move on.

Be T shaped. Know the landscape and only worry about depth in your current area of practice.

Possibly, but we don't yet understand the mechanics of reasoning. What more fundamental components are sequenced to produce the activity of reasoning?

For example, I personally think reasoning is downstream of at least generation and discrimination.

You could think of it as increasing the density of potential output for a single person, for work that can be systematized. Let's just assume many of the challenges around control and accuracy are resolved.

So certainly it can be good for indie product builders that can create things which make repeatable services into saas. And it can help them do it faster on the LLM code side.

It may indeed lower demand for swe, but those who adapt and can use the tools to produce more per person will continue to be in demand.

There's a counter-intuitive thing with these frameworks, and with golang + microservices in general.

Once the framework is in place, there's very little interesting code left for the daily developer to handle. It boxes in the regular feature work. You're left with only bland, business logic coding. As a result, you rarely need to leverage the more interesting parts of golang.

I'm surprised we don't see more DSLs inside these services, though maybe that will happen as generics gain favor. I'm also surprised how many developers want to work with golang given this dynamic.

Do some research (maybe you already have), and then just reach out to their founder/CEO directly. It can't hurt to have a conversation.

Good stuff. The HN api is fun to build with.

A couple minor bug reports:

* On the view without email page, the button still says get alerts which was a little confusing

* If my phone auto adds a capital letter for a username, it doesn't find the user. Maybe set the matching to be not case sensitive.

Have fun, and keep building!

If your degree is in computer science, it's generally presumed you will emerge from school as a junior software engineer regardless of the specialization. Plus, software engineering education in school can be really hit or miss compared to industry practices.

I'd recommend doing the ML specialization and just picking up SWE in various class projects and side stuff along the way.

Often, the original intent for such a system being deployed is positive and genuine. The person(s) wants to help improve culture and individual behavior.

However, the system doesn't stand alone. Giving and receiving good feedback is a skill. Coordinating, interpreting, and using it is a lot of work and generally it takes good managers to really make all this work. It's difficult and takes a lot of time.

So, when time gets tight or the good manager gets tired, everything will regress. At best it becomes a chore for everyone. At worst it becomes negative leverage used by HR or people with an agenda against you.

This is a great approach. It's a lot like the tactics used for building consensus.

Use whatever allows you to get the products completed most quickly. Optimize later.

I'd say the most difficult are convincing someone of something (persuasion) and giving feedback.

Persuasion is maybe the most difficult outcome to achieve. Giving feedback is the most emotionally challenging and nuanced for both parties. And of course giving feedback is often attempting persuasion too.

Occasionally, just listening and not trying to inject your own intents is hardest.

The bogleheads resources are probably a good place to start:

https://www.bogleheads.org/wiki/Main_Page

https://www.bogleheads.org/wiki/Getting_started

The market will determine this based on supply and demand. Look around and see what the median pay rates are for your market.

Pay is sometimes correlated with difficulty and complexity of the task. So high difficulty will often lower the supply of people willing/able to handle the task.

Occasionally, the domain will matter more. More people want to work in gaming, and fewer want to manage systems out on an offshore rig.

Do it. On those two mornings/days, just try and fit in the 90 mins elsewhere to make up the overlap if you're ever behind. At least try it out a semester and see what you learn.

There's usually a very small, purpose built model for hearing the initial starting phrase (Alexa, hey Google, etc). It's called a wake word model or wake word detection. Because it's a separate component, it's then fairly straightforward to disable it during an active conversation.

The joy returns in situations where it isn't software as a team sport.

I'm very capable in group settings, but it's far less fun for me. It's a continuum of the larger the team, the less enjoyment. Working on projects I choose, alone or with one other person, is the environment I enjoy most. There are tradeoffs with each, but I prefer those constraints.

What is the relationship between indie hackers / devs and rock stars in your view? Are you implying they are the same? Different?

There's a monthly Freelance thread which covers this:

Here's the one for May:

* https://news.ycombinator.com/item?id=40224211

Can you elaborate on how being a PM changed your view on protecting your energy in SWE?

Why not ask the customers? It's great you have some traction and their actions are leading you to a direction where they find value. Lean into that!

In any event, no need to make drastic changes. Maybe idea 1, but definitely not wholesale changes like 2 and 3. There are plenty more options on the table, such as:

* make two submit buttons in chat area (chat vs mindmap)

* support very specific mindmap commands and use simple string matching for intent detection (not models)

* create a way for people to choose either chat or mindmap commands for the right hand sidebar

* add more example inputs (like the "show me a summary") to guide the users

* etc

Most of the controversy is tongue in cheek fun, from the numerous co-ceo staff. It's hard to keep so many people aligned.

Perhaps though, it's because it offers significant difference to the deep abstractions embraced by r eact and friends.

Is holiday buy-back a European thing?

First, that sounds normal, and it's fine to encounter this feeling. Facing unknown challenges is a big part of creating new value.

Next, it's time to take a day and spend some time planning. Bring clarity to what your goals are for the next couple of months. Having a small set of clear priorities, allows you to ruthlessly defer and minimize everything that isn't absolutely necessary. It's less overwhelming to deal with only 1-2 things like this at a time.

I generally agree with the tactics suggested here by zer0.

Make your manager aware, so they start paying closer attention, but be wary of asking them to act for you as you don't know what they might do to make things worse. They don't sound like a good manager in terms of managing social cohesion.

Then, start experimenting with tactics to interrupt these problem folks and get them back on track to clearer, group oriented communication. What often happens in these scenarios is many people are quietly tired of it just like you. If you gently and politely push back, you'll soon find the other voices come alive to help and join in. It might take a few weeks.

Also, I don't think I'd take the risk of running into similar problem people at a new job for a guaranteed pay decrease.

I've worked on teams where I felt outpaced, and also worked on teams where I wished everyone else would give things more energy. It's hard to find good matches and also find a good group pace that is sustainable for delivering value over the long term. It's also normal to ebb and flow.

With that said, it seems like the key to your current situation is to increase your estimates to match your reality. Don't worry about what other devs think. Many product folks (or whomever is applying pressure) appreciate consistency and reliability just as much, if not more than, high velocity.

It looks like maybe you could benefit from having the headline text be more concrete. The value may seem obvious to you, but it is a bit vague to me when I read the initial text and then skim down through the page.

Here are some example questions I have:

* Who are the communications from?

* Who are they writing to?

* Are the comms for technical support, general questions, or something else?

I may be wrong, but it sounds like you're focused on the how (the knowledge base and the AI). Perhaps it would get more demo contact traction if you tried some different landing pages which address very specific use cases and make the headlines much more specific.

Here's what I mean:

Imagine you're running ClassyComms.com. The first niche you're tackling is helping your support team write better, faster responses to their external customers.

So the headline is:

Write clear and helpful responses to your customers in way less time!

Anyway, you get the idea. For the sales copy, focus on the customer tasks, and less on the how. Good luck with your venture!

For a long time, I didn't feel like commenting for various reasons. Then, I decided to try it as an experimental practice, to get more comfortable with putting my words out into the world. I guess that experiment continues.

What I've discovered so far, is I enjoy answering Ask HN questions the most. So I keep an eye on the new Ask HN submissions, and comment when I see something where I might have something to say. I especially like when I can share from a place of personal experience and help someone else out there in the world.

First, you're not alone. The desires for autonomy and agency are a continuum and people are spread along it. It's indeed unfortunate that "software as a team sport" is sometimes treated as orthodoxy in modern business. You might enjoy the relevant section on Derek Sivers' about page:

* https://sive.rs/about (ctrl-f "love to work alone")

Second, you know what's next. You need to find a way to direct your desire to something besides your employer, on a daily basis. This is not a unique problem, but it isn't easy either. You'll have to decide (for the near term), whether that target is some alternative income stream, a more fulfilling hobby, or a mixture. Then you'll have to make the recurring effort.

Some people put in time on their goal before "work". Some people figure out how to mentally downshift at work. Some people just quit and burn the boats. There are many paths. It all starts with clear and concrete goals. Then try, fail, and try again. Good luck, you can do it.

It's pretty straight forward in terms of pros and cons.

Cons:

You'll need to tighten your budget to account for the missing 12k. Depending on your country's tax rules, you'll contribute less to government benefit programs, which could have a small effect later. At worst, you'll see how you could have tightened your budget already and been saving and investing that money (12k over 10 years can result in maybe 150k).

One last con. If you do this, but don't follow through with effort, you'll potentially carry that mental weight. It seems like you're already past that kind of problem though, given how well you've used your time to build something else successful.

Pros:

There's no better time to trade back some money for your time than when you are younger, get paid less, and have fewer obligations. It's also easier to tighten a budget when you live alone (you don't say, but I'm making some assumptions).

You've already had some success, so committing more time to this effort of independence can be seen as a reasonable and even smart investment. Strike while the iron is hot.

If you start earlier, that gives you more time to slowly build successful independent software businesses, and you'll need that time. It can take a while.

As others have said, you can always go back to working full time (maybe with another job and maybe even a pay rise). You can further mitigate risk by setting some sort of arbitrary deadline, such as "I'll do this for 1 year and stop only if I haven't made more traction".

Parting thoughts:

I wish you the best of luck. If you haven't already, it seems like you'd enjoy and benefit from Pieter Levels book at https://readmake.com.

What's your list of paradigms?