[bmitc]

If anything, my confidence gets lower as I get more experience. The amount of politics, power jockeying, engineers who hide behind decisions as if they were technical only to be highly personal preferences, how many people reject simplicity and prefer complexity while calling it simple, lack of documentation, etc.

It just all makes me feel like I don't belong in the field. It's all so overwhelming and complicated, and any attempt to try to make something more simple or documented is fruitless if even accepted. People just can't see to be able to wrap the idea around their heads that one thing doing one thing is simple and not "tedious" or "verbose".

The reason why my confidence lowers is that everyone else is seemingly okay with all of this and continuing along the trend. Meanwhile, I feel like I'm just continuing to participate in building giant balls of mud that just barely work and are just barely understandable. So there's an impedance mismatch, and I face it so much, I just have to wonder if it's me, that I'm not smart enough to push through all the cruft or figure things out or just don't understand how to design. Thus, the low confidence. It's just all very confusing.

I would be somewhat suspicious of anyone in software engineering who purports to having figured it all out or having confidence in the field.

[Arisaka1]

I usually don't respond to comments, but there's a lot of things that I can identify with in your comment and I'm far from experienced as a developer.

>The amount of politics, power jockeying, engineers who hide behind decisions as if they were technical only to be highly personal preferences, how many people reject simplicity and prefer complexity while calling it simple, lack of documentation, etc.

Learning on my own and participating in online communities, receiving feedback and coming up with project ideas led me thinking that this field is creative and people treat it as a craft. The hiring process has you either do leetcode, show off your projects and talk about them or both.

Given the above, it's easy to understand why someone would expect to see the same in the job. But instead what you get is completely the opposite. My first job felt like I joined a restaurant that actually is a fast food joint, and the metric of performance that makes people happy is how many burgers I can churn during a sprint. Documentation? Can happen later. Testing? Slows us down, test by hand.

And on top of that I had teammates who refused to use the phrase "I need help" and "I was wrong", almost as if it's a sign of weakness. I don't know if it was their upbringing, culture or just because they had to demonstrate perfection to show how worthy they are of their position, but it sucked and I ended up spending more time tiptoeing around their ego than being an actual junior engineer, so I had to quit and recalibrate my career goals.

[knoester]

I'm sorry you had to go through that. Sadly, IT is full of 'colorful' characters like these. I've been on multiple projects that could have been so much more fun and lighthearted, were it not for 1 person. Due to their influence (whatever it is) the atmosphere completely changes and eventually people lose interest in the product, burn out, quit or are laid off because of it. No good can exist without the bad I guess.

[SQueeeeeL]

Writing extremely good quality software is hard and expensive. In the vast majority of cases all you need is okay software developed by people who just want to get the job done. Understanding how software creates value and what kind of software at any moment is valuable; and which parts of your job is tied to that process makes this much clearer.

If anyone reading this just want to write bash scripts that don't violate fundamental principals, there are jobs out there, but they're typically low paying and academic

[bmitc]

> Understanding how software creates value and what kind of software at any moment is valuable; and which parts of your job is tied to that process makes this much clearer.

This is a good point and something that is indeed requires a lot of care and thought and experience to tackle properly, but I think it strongly hinges on the assumption that software just does a thing, so to speak. Whereas I personally view software as something that does a thing but at the same time as something that is also a communication system and encoding of domain knowledge. So if the communication and encoding parts of the software are missing, and all you've got is it doing something, then in my view, the software is leaving value on the table over the long term. Poorly tested, understood, documented, and specified software will have waste products over time, siphoning value away. But it does so much more quietly, but in no less magnitude, than when software is not doing what it is supposed to be doing.

[SQueeeeeL]

You are correct, but current geopolitical conditions and economic policy have created financial situations that basically enforce short sightedness on the side of corporations. If your employer is publicly traded or has institutional investors; they need to report quarterly earnings. Investors won't care about code health or the longevity of a product, they only care about sales/revenue.

It's a fundamental systemic issue that's why we see so many tech companies produce terrible products. But we (the programmers) have no ability to fix the shortsightedness of the American financial system.

[Tokumei-no-hito]

Do you have any examples from your experience about making that distinction? Sometimes I struggle with the boundary between good maintainable code and meeting deadlines.

[sh34r]

Writing bad quality software is often even more expensive.

[halkony]

It sounds like you have a commitment to excellence not shared by your peers. As sibling comment points out, good enough is good enough for most businesses. I like Paul Graham's quote from his book. "The goal of big companies is not to write quality software, but to suck less than their competitors."

My confidence as a software engineer comes from the gratitude of my users. Giving them something that makes them light up and say "I had no idea I needed this." I've worked in many organizations where layers of bureaucracy smother that joy. Having a direct line to my users is incredibly motivating.

Many comments touch on the "do it for the users" mentality and I'll add my own take. There's a book called "The Science of Drawing" by Harold Speed. It's a pretty rigorous dissection of drawing written in 1913. However, despite its clinical writing style, the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction. Dissecting art is only as useful as a means to produce more of it, the emotional communication is the actual core of the medium. Software is very similar in this way.

[bmitc]

Thanks very much for the encouraging reply. This is rather helpful and deep advice.

> It sounds like you have a commitment to excellence not shared by your peers.

Just to be clear, my sentiment is one built up over time and experience and not directed at any one company or colleague. There are kernels of this everywhere though. I'm also a part of it all. I've definitely made things more complex than they've needed to be, but I do attempt to learn from that and revisit approaches.

> Giving them something that makes them light up and say "I had no idea I needed this." ... Having a direct line to my users is incredibly motivating.

This is a really good point, and thank you for saying that. Your advice here is very helpful. I have had the most fulfillment when having a direct user being able to use software I've worked on to do their job better.

> There's a book called "The Science of Drawing" by Harold Speed.

Thanks for this book recommendation! I'm going to check it out.

> the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction.

Even though it was not intended this way, one of the greatest complements I ever received on software that I personally and solely wrote was someone opening up my code and saying "where's the code?!" in a completely bamboozled way and also a way in which they were legitimately worried if it actually did anything. Haha. They were used to hodge-podge collections of code stuff into a single file doing absolutely everything under the sun. So when they opened up my code, they were legitimately bewildered that everything was modularized, componentized, etc., and for a half minute they were suspicious that there was even anything implemented. It was confusing to them that things were labeled simply as "do this specific thing" (as an abstract example), and it actually just did that specific thing rather than a block of spaghetti code doing something but god knows what.

[silveroriole]

Judging by my performance reviews, I’ve gotten way worse at my job over time. They LOVED me as a junior, they despise me as a senior/lead. Only difference is that as a junior, when the boss came by and said “let’s do it this way,” I said wow, cool, teach me! Now I say “No user has asked for this, your design is overcomplicated, and we need to factor in an extra three weeks for the overdue tech debt fixes I’ve been warning you about.” And the reaction towards me actually using my knowledge and job skills is so extremely negative that there goes my confidence. This industry is kinda screwed up.

[sh34r]

There are a lot of zombie companies that only exist due to bailouts and zero interest rates. Sounds like you’re at one of them. Inflation and interest rates aren’t going down any time soon.

It’s all cyclical. The decadence today will eventually give way to another recession, and we’ll build something better from the ashes.

I’m also growing increasingly disgusted by the state of the industry. Things weren’t so messed up 10 years ago, but salaries were also not so ludicrous at the time. I suppose I should be careful what I wish for, but I’d appreciate some disruption right about now.

[sh34r]

I couldn’t agree more.

I could live with apathy towards documentation, but it goes beyond apathy. There is often outright hostility to anyone who “wastes time” writing documentation or doing design work. Agile grifters have absolutely ruined this profession.