Have you considered teaching people in your org how to become like you, how to take over your code?
Tell HN: The loneliness of a pretty good developer
131–140 of 519 posts
Re: Tell HN: The loneliness of a pretty good developer
#132Have you talked to your manager about all of this?
Re: Tell HN: The loneliness of a pretty good developer
#133Congratulations on your progress. Guitarist Pat Metheny has suggested one approach to growth is to "Be the worst guy in every band you're in." Dave Hoover applied that to his own learning in software development and wrote it up, first as a blog post [0] and later, with Adewale Oshineye, as part of a book, 'Apprenticeship Patterns.' [1]
The implication is that you could consider finding a stronger team to work with, which might involve a job switch. There are much larger issues there, involving salary, benefits, commute, effects on family and friends, and only you know the the full picture of the effects of those things on your own happiness. I can say there's a place for keeping an imperfect job as part of a pleasant overall picture. Good luck as you explore your options.
[0] https://redsquirrel.com/dave/work/a2j/patterns/BeTheWorst.ht...
[1] https://learning.oreilly.com/library/view/apprenticeship-pat...
Re: Tell HN: The loneliness of a pretty good developer
#134Earlier quoted context omitted.
Or he just bangs out a ton of crappy code in the name of "pragmatism", while everyone else has to clean up after him and thus takes longer. I've seen this many times.
Eh, that is exactly what I don't want. Pretending I am this amazingly productive developer and my code is just trash. I just checked. In 2021, only two defects were created against my specific code changes. If I had to home into a weakness of mine is that sometimes I solve today's problem well, but don't think extensively about how tomorrow's problem in that space might look like. The struggle is between creating sim…
It's not about behavioural defects. It's that the _code_ is trash. It is unmaintainable and slows down all future changes, exactly because the person who wrote it didn't take the time to think about the future or even good architecture in the present. Every time I touch their code I have to almost redo their work because:
- It's impossible to understand what is going on (For example when people load huge json or sql files into a single test and you don't know what scenarios it covers because they are too lazy to write dedicated minimal test cases. Another common offense is a not well-defined data model that gets mutated everywhere in dynamic languages like Python or JavaScript where you never know what shape an object has or where it comes from)
- Their code allows so little extensibility that following the same "pragmatism" as they did and just hacking it in would exponentially increase the complexity
- There are no abstraction boundaries which almost surely means insufficient test coverage (which I have to amend before I can even start with my own work so that I don't introduce regressions) or the tests are coupled so closely to implementation details that any change necessary for my own work will require me to rewrite all the existing tests
You are fast because you pawn off your design work to whoever comes after you. Of course you have fewer defects: your colleagues have to put in more time to maintain the same level of correctness or else risk introducing bugs. That's the cost of bad maintainability. It's well known that changing existing code is harder than writing new code, double so if it is not written with care. Someone has to be the janitor to keep the cruft from accumulating and if it's not you, then everyone else has to pick up your slack. Ideally, every person in the team would continually clean up and always leave a code base better than they found it.
Lastly, I want to say that there is very important difference between simple and easy and simple doesn't come for free.
Re: Tell HN: The loneliness of a pretty good developer
#135> The problem is people just accept whatever I say. I used to get challenged in some of my decisions, which I always appreciated since I could create better solutions. Nowadays people just accept whatever I say as the best way.
This struck to me as familiar. Not because I'm anywhere near as uber, so to speak, as you seem to be, but because I've noticed the pattern with junior developers, especially people new to the company/team and myself.
What I've tried to very consciously do is to make sure I ask other people about their opinion. I also sometimes deliberately add stuff like "not sure if I'm correct, correct me if you think I'm not, but..."
That usually makes these type situations a bit more interactive and probably less lonely. Also great opportunities to really have conversations about technology choices. I often learn new things along the way as well.
Re: Tell HN: The loneliness of a pretty good developer
#136Earlier quoted context omitted.
I was more thinking about the kind of guys I've known who've liked throwing around nonsense like "simps". But if it hasn't yet occurred to you that helping other people develop their careers is also a great way to develop your own, I don't suppose I'm all that likely to disabuse you of the oversight.
In my experience, it doesn't help at all. Move to SV and you'll understand.
I looked at it early on, right when I was starting out. That was a little before the dotcom crash, enough that only the really smart people were starting to think it was coming. Everything there looked amazing, and everyone I knew there was miserable every day, and I couldn't spend all my time in the Castro. So I took a powder and ended up in Baltimore.
I wasn't sure I'd made the right call till a few years later, when I heard one of the guys I'd stayed with then had killed himself. Sure, so maybe I missed out on a shot at some lottery tickets. So I'll never have fuck-you money, so what? Neither will almost everyone else - we call them "lottery tickets" for a reason, and that's before we get to the shitshow the next five years are going to be.
With the time I didn't waste chasing after them, I've managed to build a hell of a good life for myself, work included. I sit every day in an office full of windows and surrounded by trees, and I'm even still able to enjoy the birdsong once in a while. I don't have to look very hard for good jobs by now; mostly these days they come and find me. I don't want for a thing in this world that money can buy. And it's been a very long time since I had to work with anyone I couldn't find a way to like.
So yeah, the choices I've made have been more than worth what they cost me. Can you say the same?
Re: Tell HN: The loneliness of a pretty good developer
#137I'm 37 and probably have a solid xp, 'probably' because I'll never call myself a 10x or senior, just by some sort of personal modesty. And maybe that helps me to stay motivated, to stay ground to earth, just my 2cents, no criticism, just some relief on the situation, best continuation!
Re: Tell HN: The loneliness of a pretty good developer
#138If you are a truly a 10X developer(TM pending) and this is not one of those copy-paste kids love these days, you could found your own company or consulting agency.With the huge competitive advantage you have (probably unique in the world ) : a 10-men-strength worth development capability that only have to maintain 1 family. If mere mortals have founded companies solo or in pairs, imagine what you could do with 5-10X the productivity and brain power.
Re: Tell HN: The loneliness of a pretty good developer
#139How did you become a more productive developer?
I can go really deep talking about this, so I will just write my personal system pointers that I keep by my desk.
Iterate fast > perfect
Write it down to relieve cognitive load.
Uni-task (focus on one thing at a time)
Prioritize and execute.
Solve problems by:
a. Invert - improve by subtraction
b. Decision trees - compare outcomes, reduce load
There are two types of decisions. Hard choice (A vs B), or multiple factors (A vs B vs C, but you can do A+B etc).
Hard choice model. Is it a hard or easy choice? Does it have low or high impact. Hard to compare, low impact = apple vs oranges, focus on optimization.
Hard to compare, high impact = get impact and mitigate negatives.
Easy comparison, low impact = Go with your gut
Easy comparison, high impact = Be confident
For multi factor decisions use a decision matrix.
Understand systems by looking at the connection circle or iceberg model.
Connection circle is when you take the key elements and put them on a circle as points. If there is a cause and effect relationship you draw an arrow from one element to another. If arrows end up connecting three or more elements together you have located a closed feedback loop.
Iceberg model, top of the iceberg (what's visible) is the event that just happened, underneath that there are patterns/trends, under that structures and connections. The deepest part of the iceberg are the mental models and assumptions made by people. If it's a system I don't understand I will confirm my path down the iceberg by looking at the code, testing the code and talking to SMEs
In terms of actual code reminders I try to make it work, make it right, make it fast.
I also try to do always, then inhibit, then ignore cases that don't apply.
Minimize if statements to have consistent execution.
If a function is called from one place I will inline it. From multiple places I will try to see if I can have it happen in one place so I can inline it (plus it's an optimization thing). For complex calculations if I can't have it happen once I will try to cache it, but cache invalidation can get tricky, so I always opt for do it once.
Finally I try to write pure functions, look at parameters and return one or more computed value.
Re: Tell HN: The loneliness of a pretty good developer
#140I've heard CEOs say "it's the loneliest job in the world". Their solution? Peer groups; CEOs of different companies meeting informally on a regular basis.
If you're not angling for a CTO position, though, switching jobs is the best way to find a better IC "peer group".