[dead]
Ask HN: I've lost faith in myself as a developer, how do I get it back?
161–170 of 243 posts
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#162Imposter syndrome (n): 1. delusions of mediocrity.
I've been faking imposter syndrome for the past thirty years.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#163I highly recommend reading the Linux kernel management style guide at https://www.kernel.org/doc/html/latest/process/management-st... . It has this gem of a quote: > It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always u…
Can you explain the last sentence of the quote? Seems ambiguous.
I think it means that when you are conducting your evaluation, you are doing more than just solving a technical problem.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#164Build little things that work, with no economic pressure. Join a Open Source project and build something people could need or love. Not big, just a little feature, a little help.
Seek contact to those using your software.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#165I highly recommend reading the Linux kernel management style guide at https://www.kernel.org/doc/html/latest/process/management-st... . It has this gem of a quote: > It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always u…
This observation is profound, and also resonates with my experiences across different companies, some of which had highly mission critical / reliable systems.
I used to imagine from the outside that such places must have highly elaborate testing regimes, backup systems, and genius-level developers. However, my lived experience is that they're just really good / disciplined about reverting to the previous known good state and backtracking. Much like a source control system lets you undo a bad change and go back to a known good solution, they do that with their releases and entire system.
Some anti-patterns are "roll-forward" with a fix for a problem (if you failed to reason about the original change with the problem properly, how can you be confident that your "roll-forward" / hotfix / patch will work? Roll it back, try again in dev, roll forward again.
This also means avoiding changes that can't be rolled back (because they wrote data in a new format that the previous version doesn't understand) wherever possible (and it usually is).
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#166There is no right way. Anyone who calls you out on doing things the wrong way, is wrong. There are better ways.
Except, if you're not listening at all to suggestions from colleagues, then you may be doing things the wrong way. Or when the code is just failing at doing its task.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#167Earlier quoted context omitted.
> Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions There's a cautionary tale buried here. Many seemingly Type 2 decisions are actually Type 1 decisions in disguise. Case in point, Amazon's decision to not allow warehouse workers to have their phones when working in the warehouse has resulted in the 6+ deaths and many more injuries that we saw in the tornado last Friday. Now there's no going back,…
The lack of emergency alert was the main factor, not the cell phone policy just because cell phones have an alert system built in.
I accept all of your premises but disagree with your argument -- yes the lack of an emergency alert system is a factor, yes cell phones have a built-in alert system that could have handled this, and yes Amazon chose to suppress this alert system from working by denying employees access to their devices. They took away the only existing alert system and didn't replace it with anything. Garden variety negligent behavior leading to deaths.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#168Earlier quoted context omitted.
> Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions There's a cautionary tale buried here. Many seemingly Type 2 decisions are actually Type 1 decisions in disguise. Case in point, Amazon's decision to not allow warehouse workers to have their phones when working in the warehouse has resulted in the 6+ deaths and many more injuries that we saw in the tornado last Friday. Now there's no going back,…
This is nothing to do with one-way/two-way door decisions, you are conflating that concept with an understanding of "unintended consequences" in order to take a cheap shot at Amazon. Ordinarily I'd enjoy that as much as the next person, but this case is too ham-fisted to leave unchallenged.
You're missing the point. The point is that even the most mundane decisions can lead to irrevocable negative situations, so one should think about worst case scenarios with every decision, as engineers are regularly trained to. Classifying things as type 1 or type 2 decisions can create a blind spot, as it did in this situation in my humble opinion. In reality anything can become a one-way-door decision.
The "dunk" is a side effect. Amazon's decision making on this issue does a really good job of illustrating situations where you make a seemingly harmless decision that you feel you could revoke at any time, but things take a turn for the worse and regardless of your ability to revoke the decision, you can't revoke the damage it caused, the preventing of which is the whole purpose of having this system of type 1 vs type 2 in the first place. AKA the type 1 type 2 system is imperfect and can lead to miscalculations, like this. A more useful framework might be "can I prove, convincingly, that there is a 0% chance this decision will lead to irrevocable significant negative consequences, if so then it is type 2, otherwise type 1"
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#169I highly recommend reading the Linux kernel management style guide at https://www.kernel.org/doc/html/latest/process/management-st... . It has this gem of a quote: > It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always u…
Can you explain the last sentence of the quote? Seems ambiguous.
If you mean this:
> the wrong one and the right one.
The context comes right before it:
> if you were wrong (and you will be wrong), you can always undo the damage later by backtracking
Ie: do a (small) wrong, then do a (small) right to fix it. That's my reading of it anyway.
Re: Ask HN: I've lost faith in myself as a developer, how do I get it back?
#170Earlier quoted context omitted.
> I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about. This is the sad truth at way too many orgs, even YC funded ones. Several times I have come in…
Any tips or lessons learned on working with the non-technical folks? This is a struggle I am dealing with and am constantly trying to improve in. They want to do things their way, which might work okay but is inefficient and not in line with the technology goals of the company. Hard to wrangle them - they run off and do things without talking to me or the people in my department, not considering the plans technology…
Unfortunately what has worked best in practice for me is:
1) Curate your resume and experience for years so that people will take your opinion very seriously (whether you deserve it or not)
2) When you know something is going to fail, call it out in advance with stakeholders and do whatever you can to pump the breaks and/or change course. If you have a lot of respect, you can use this to force an uncomfortable decision that someone without much respect might not have been able to push through.
3) Be VERY insistent in pushing your proposed mitigations when you know something is going to fail and know what will fix it. If you're sure, stake your career on it.
4) When people don't listen, and things fail because they didn't listen, in yearly review / feedback type things say "if only I had pushed harder for X, then Y might have been prevented" which is a nice way of saying "should have listened to me". Eventually everyone will just listen to you in the first place.
5) If you see the writing on the wall and no one is listening to you, exit while conditions are still favorable (I never actually do this, but I probably should).
6) When you are wrong, take responsibility, but only for the parts that are actually your fault. In reality the surface area of any one person's portion of blame in most situations is quite small anyway. Most decisions in orgs can be traced back to at least 4 people.
7) Make accurate predictions of failure if we don't take X course. When these come to fruition, you called it, when they don't, you still come off as very prepared for anything.