The conversation

yargHNSource author
Lessons learnedExperience excerpt · English

I worked in an environment where a senior architect got to veto every major effort that I …

I worked in an environment where a senior architect got to veto every major effort that I publically made to improve the structure and maintainability of the software. At some point I got so pissed off about this that I started assigning code reviews to him - he contacted my manager and asked that I stop, because he had no understanding of the project in question. What did this mean from the documentation side? I would have loved to accurately document what I was doing and how the project was structured - but I actively avoided doing so. Every time my manager's boss knew what I was doing, I was about to be shat on from great heights. Months of work and planning erased at the drop of a hat - time and time again. Dependency injection? Fuck off. Spring's too heavy. Modularity? Fuck off. The project's too small. Hierarchical profiles? Fuck you, keep using a properties file (with an increasing number of dynamically generated keys). …

Original discussionTheory-building and why employee churn is lethal to software companies420 source comments · at import
5

What was this responding to?

Parent context · original excerpt

BE
bentobeanHN

> Documentation only works up to a point because it can both get out of sync with what the code is doing and because documenting the internals of a complex piece of software is a rare skill. A skill that most developers don’t possess. Most internal documentation only begins to make sense to a developer after they’ve developed an internal mental model of how it all hangs together. Most code documentation becomes useful after you have built the theory in your mind, not before. It operates as a mnemonic for what you already know, not as a tool for learning. This is ringing particularly true to me right now. The organization I work for has allowed bit rot to occur for a number of years, to the point that it's becoming increasingly common for things to break whenever even seemingly small changes are implemented. The "solution" that we've implemented is to require a detailed RFC document whene…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 5

Direct replies available in this import. Original-language excerpts.

AN
andrewmcwattersHN

Here's the kicker, I hate to say it, but they probably didn't notice you left. That's the thing about places like that.

Full original
DE
devwastakenHN

It's a job, not the fifth world wonder. That Corp is making money based on their market position, the software functioning is an afterthought. If it all breaks, the customer isn't going anywhere. Don't fight management, leave.

Full original
BE
bentobeanHN

I hear your frustration. I can relate. But this: > I was damned near suicidal from fighting for acknowledgement I sincerely hope this was hyperbole. Please don’t ever allow anything work related to affect you to this extent. You are more than your job. There are other opportunities. There is much more to life than software.

Full original
GE
geodelHN

Well, FWIW I have to use all the things you were proposing. However I find them eminently crappy and if I were in a position at my workplace to reject them I would have absolutely done that. > I took an unmaintainable pile of bugs and made it stable and maintainable. Same here, except it was supposedly using all best practices e.g. Spring Boot, DI/IoC, Mock testing framework, YAML configs, extremely elaborate package hierarchy and so on. The only thing it did not have was working solution for the business problem it was written for.

Full original
JA
JAlexoidHN

Your comment is why everyone should start their engineering experience as a consultant. Primary thing that I learned being a consultant - you can leave and you don't have to suffer the disdain from the management. You learn to disconnect yourself and be replaceable. It makes for a less frustrating life. Sad that it happened to you. Don't invest yourself in someone else's child.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.