Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
You don’t have a “Brent” problem. You have a organizational structure problem. You don’t appear to have functional teams, those teams don’t appear to be responsible for supporting their crappy shit, and no one is testing effectively.
If everyone on multiple teams is responsible for quality for one repository, then no one is.
Agile, or better yet Lean, documentation is minimal. As soon as it’s in the Wiki it’s obsolete unless it’s just focused on principles and practices. Application documentation should be in the repository README.md or, best yet, written as functional tests.
Again, Brent isn’t your problem. You’ve no constraint like that. What you have is chaotic development. That needs to be fixed first.
@yamatoman we're a single team but the app is very large. Don't even get started about other teams we need to deal with...
But take 1 project for example, there's like 50 packages, 1000s of source code files.
We have JIRAs and whoever is assigned the ticket makes the change/feature.
That maybe the problem. But basically there's 1 entry app and it runs all other apps (Spring configs, DI setup).
New process? Add a new package. It may use some common components or create new ones.
Another example, some of the code I wrote a year ago. I come back to it and now the logic had changed, there some new usage, requirement added.
But I dunno what or why and now I need to melee a change.
And for readme. Yea I have my own but not sure where to put it. Do I check it into the repo? Where?
But maybe that's a solution. All processes/packages need to have design docs (readmes) checked into repo...
But could also cause a mess and make the git history huge...
My conversations with my boss tend to be like:
-ask ... about... He should know
-oh he left, you'll have to see what you can find from the source code and wiki
-work with the business to figure out where wrong with ... And fix it
And so a lot of things get out on hold or I there's a lot of time spent doing required or I think stepping on top of each other.
Lately been getting the feelings of move fast and break things, shoot first ask questions later, bring in the Wild West where everything is always changing. I leave something for a month come back and now it's broken for some reason...
And getting information feels like squeezing out of an almost dry rag... Where really this info should be written down and in plain sight...
Feel your pain. Been there and it takes a push from devs and upper management to fix. On my old team, we focused heavily on application and test design to make sure that we protected ourselves from chaos when timelines compressed. One of my old team members moved to a company on the east coast that’s a startup that doesn’t test shit. He’s now living a nightmare and wishing he hadn’t had to leave. What it sounds like, and correct me if I’m wrong, is there’s no real design. You have a giant entangled monolith with minimal real testing. Processes are pretty manual, and the team is either bigger than 10 people, doesn’t know what “good” is, or just doesn’t give a shit. All of those situations suck. You can try to start changing it. Bring in hygienic coding practices, BDD, TDD, C4 design, etc. keep pushing. Get management support. If that doesn’t work, we’re hiring people who give a shit. :)
Regarding the readme: yes, commit to version control with the source. See every good OS project ever.
@yamatoman thanks, pretty much what I feel. (actually rereading my reply, so many typos, amazed you actually understood it). A lot of manual stuff, and I'm probably slowing down as well... My last team I ended up being the only dev so owning the whole code base (4 medium apps), I cleaned up and automated so much, there wasn't much left to do by the time I was transferred.
When I first joined my current team, I told my manager and his manager... read The Phoenix Project AND follow it.
I remember a bit of BDD and TDD (I m usually the only person that "yells" at business ppl and my boss to specifically define their use cases with real inputs and desired outputs). I prefer not having to change the whole design halfway thru when all the specs suddenly change because now they have a "better" idea of what they actually wanted... but the deadline is still the deadline...
Not familiar with C4, will take a look. The other problem is the senior devs (their code quality leaves much too be desired) are too busy to review jr devs code.
There's no time for code review and i m not in a position to demand change. but the original problem is still lack of docs so ppl can get up to speed quickly when needed.
Some days I feel, i m going at 10x coding what i need, then i m suddenly given a Prod issue (because i m the guy that seems to be able to figure out anything) but because I have to dig thru stuff, i slow down to .5x... and all my plans for the day go poof...
@billgates you have terrible management. Company I work for has pockets like that and pockets like mine. Being a fortune 5 company, we pretty much have everything, really. I’d find someplace that meets your standards. Life is too short to be prevented from reliving something you’re proud of.
@yamatoman the other part I think is that ppl should be made to clean up their own shit... Otherwise they'll keep making shit...
I tried looking for better but not much luck get stuck on technical interviews and not being a good fit.
Never really understood technical interviews much... what's so good about knowing how a Tree works when you'll never use it (even when you should) on the job... And ur code looks like shit...
Nowadays I'm sorta shifting I guess, spends more time on life than work... Just need to work to pay the bills...