Aura Tracker: Habits & Goals is now live on the iOS App Store.

It's an opinionated productivity system that connects Identity → Goals → Habits → Tasks → Deep Work → Insights → Reflection, all in one smooth coherent flow. I built it because most productivity apps I used felt like productivity tools. Also, I was highly influenced by the multitude of books I read on the topic and wanted to build something for myself where I can put all my learnings into use.

PS: This was kinda on my TODO list for like almost a decade. I quit my job last year to go full solo founder mode. As long as I was employed, I used to keep watching others posting Show HN and kept wondering when my time would come. Now that it has, it feels so good. Just the same kind of joy I felt, when I wrote my first "Hello World" program on Turbo C editor as a kid (long ago).

Not sure how this product would do, but the feeling that I built something that's gonna stay forever on the internet (and hopefully change the lives of whoever uses it for the better) is a feeling that no amount of corporate bonus or RSU's can provide !!

Comments URL: https://news.ycombinator.com/item?id=47123132

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46526199

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46499100

Points: 2

# Comments: 1

I'm a Senior Engineer at a large tech company with over 20 years of experience. For the last 5 years, my role has primarily revolved around devops, tech leadership (small teams), taking care of system architecture , feature design, security stuff, reviews etc, with much of the hands-on coding (mostly maintenance stuff) delegated to junior engineers. What's striking is that in my entire tenure here, I haven't encountered a single task that required implementing anything close to the Data Structures and Algorithms (DS/Algo) problems you'd find on LeetCode.

Now, with layoff rumors circulating in our organization, I'm actively exploring new opportunities. The challenge? Despite my extensive experience, it seems almost every company, even for senior roles, still kicks off the interview process with a DS/Algo screen.

This puts me at a crossroads. Should I dedicate valuable time to reskilling in DS/Algo, essentially studying just to pass an interview hurdle? Or is there a viable path to convince hiring managers to look past these skills and focus solely on my strengths in system design, architecture, and practical engineering leadership?

Honestly, it feels a bit absurd to spend time on "basic" DS/Algo questions after all these years, especially when current AI tools can make much of that work redundant.

Any insights or advice would be greatly appreciated!

PS: If it helps, I'm based in India, not US !

Comments URL: https://news.ycombinator.com/item?id=44367701

Points: 3

# Comments: 1

As for me, I've been a regular s/w developer and play video games as a hobby. Never built any games before as the learning curve was too steep (not to mention the various skillsets that needed to be learnt - art, music etc apart from programming). But with the advent of AI in almost all tools these days, I'm wondering if its more accessible now and building/publishing a game is easier than ever ?

Comments URL: https://news.ycombinator.com/item?id=42611805

Points: 1

# Comments: 3

Lately, I seem to see a lot of advise on side projects and having multiple income streams, but not really sure if such hustling is the only way to survive going forward! Also, feel a bit anxious wondering if everyone else with a 'stuck-in-a-rut' day job is hustling and I would be ultimately left behind !

Comments URL: https://news.ycombinator.com/item?id=41046099

Points: 2

# Comments: 3

Not trying to be pessimistic, but doesn't notion give you all these already ? Or did I miss something here ?

Work was mostly well distributed/planned well in advance and overtime was only around field testing/release dates/acceptance test etc, none of this on demand agile bs that we've these days. Every major/large feature was broken into requirements (or use-cases in some projects) and these were were written by a very senior person (or a group of them) and it would be reviewed for every spelling mistake (I kid you not) before handing it over to the dev team. We used to have workshops where people from different modules (old name for the modern micro services) would sit around a physical table (not a slack/teams meeting) and would pore through the printed document or on their laptop and one person would literally take notes on what was discussed, what were open issues for the next meeting etc. Only when every requirement was completely addressed it would get a green signal to move to dev.

Test / Dev were different teams, and in companies where I worked V model was popular where a test team would write test cases and dev team would write code against these requirements. Testing was a vertical in itself and while devs usually handled Unit/Module testing, system integration testing, field testing, customer acceptance testing were done by dedicated teams. The goal was to capture 90% of defects in MT, some 7-8% in SIT and only 1-2% from field and theoretically nothing post release. We (devs) used to have goals given on how many bugs can be expected from each of the phases to determine our quality of coding. Code reviews had a reviewer, moderator, approver and so on making it a very important event (not the offline bs that happens today). A post release bug would be a nasty escalation on both dev/test teams.

Did I also mention that the MNC had a tech support team who had good knowledge of most systems at high level, worked in shifts and unless there was a bug which required code change, would be able to handle & resolve most escalations from customer. Bugs requiring code change would be sent to the dev team only after a formal handshake between dev and support teams. The bugs would get treated the same way like a feature, and went in maintenance packages released every once in a while (same cycle of dev/testing as features)

There were separate teams in some projects, one for bug fixing of previous releases and one for building new features for an upcoming release and they used to be rotated out after a release !

I always thought that moving to agile/scrum would make life easy and fast. While it shortened release cycles, software quality has taken a huge hit, most code these days are copy/pasted , reviews are mostly lip-service and the end result is that most engineers are forced to do pager duty and are called to fix the mess they made round the clock. Interview processes are mostly focused on irrelevant ds/algo questions and abstract design problems with little to no emphasis on a candidate's experience. I had one interviewer tell me that they really don't care about a candidate's experience but only his performance in the interview matters (yeah, no sh1t sherlock, explains why the company needs 24x7 on call dev support !)

Call me old fashioned, but I do miss the old way of building boxed software (plan/analyze/design/code/test/ship and maintain). Work was relatively more predictable and office felt like a place where people actually collaborated and worked together to build something they could be proud of !

I feel so burned out and anxious all the time, not because of overwork, but due to a lack of formal structure in my work day.

I'm thinking of starting out on my own someday, but I wonder, is it even realistic to have a 9-5 kind of structure in IT/software dev field ? Whether i work for a big org / startup / myself, is it inevitable that I have to work round the clock and I've to accept it as a way of life ? Is there a sub-field in software dev where in I can login at a specific time / logout at a specific time and not have to worry about work after I log out.

PS: Honestly speaking, I used to work at IT service industry not too long ago (perhaps in mid 2000s), where I was working on a boxed software. Except for some crunch time during major releases, there was no pager duty expected, the pay was average at best and work was monotonous bug fixing, but I felt much more at peace since work was always predictable most of the time. With this on-call culture thanks to the 99.99 uptime thats become the de-facto industry standard for most companies, I wonder whether such companies exist anymore !

Comments URL: https://news.ycombinator.com/item?id=33296415

Points: 149

# Comments: 144

Many people stay back in a company even knowing they could probably get more if they try else where (ex: work like balance, friends, job security in the long term, exciting work etc). When a org has sufficient no of such ppl, it doesn't matter to them when they lose some 1-2 start performers. Also, there's no guarantee those star performers would stay back even if they are paid higher salaries !!

I'm almost 40 and there is like an ocean of people in the same boat as me (in my current company), many of them with half my experience. So, I feel like completely stuck on how to get ahead of the pack.

I've taken full ownership of decently sized projects (in terms of complexity/scale), with hands-on execution, leading the team all the way from design to the production deployment. I've tried giving team wide presentations on tech topics, took part in hiring drives and so on, but nothing seems to make any difference. I've also tried applying to other teams within the company, but they are ready to take me at my current level, but not for a higher level.

I often see people reaching the positions of architects/tech fellows at these large companies at just 10-12 years of experience, and I fail to understand what exactly did they do right. Is it all about luck/being in right place at the right time ?

There's the obvious solution of moving to a different (albeit much smaller) company, but I like the work life balance, tech stack we use and some other perks the company provides. So, trying to see what I can do here before giving up and moving on to a different company altogether.

Any/All helpful comments is highly appreciated. Thanks in advance !

Comments URL: https://news.ycombinator.com/item?id=29288596

Points: 3

# Comments: 4

1. Is it possible to build and sustain a SaaS business as a solo founder ? For a medium sized project (say something like asana/trello), how long would it take from start->finish (MVP which can be monetized) if one spends around 20 hours in a week?

2. Does one have to be super smart in the algorithms/data structures/programming language and/or a domain expert to take care of both development / customer requirements/support etc ? A feature like adding a new way of auth take at-least 2-3 weeks to complete at large enterprises with multiple folks working full time. What chance can an individual have against these large companies?

3. Is it a good idea to spend 2-3 months on learning the tech, and then start on the side project ? I'm asking this, since with a full time job , one can only expect some 2 hours a day and around 8 hours on a weekend, if most of that is spent on stack overflow,then the progress would be really slow.

4. Since monetization is tricky and not guaranteed, is it a good idea to simply work on the side project to amplify job opportunities? Or is it best to give it all as if there's no plan-b ?

5. Lastly, what's the primary reason to go and start your company instead of say spending the same 20+ hours on getting better at your current job/seeking a better job in the same field at a better company ? Isn't the latter more secure/stable option ?

Sorry if some of the questions sound obvious / cliched. But I wanted a fresh take on some of the above questions that has been brewing in my head for a long time. Thanks in advance :)

Comments URL: https://news.ycombinator.com/item?id=25177276

Points: 3

# Comments: 1