Java dev at a trucking company. Their IT shop grew organically and stuff wasn't exactly well-engineered at any level. We used Websphere on the AS/400 (system i now). When I arrived I found such fun practices as source control being a shared network directory and 63.5k JSPs (because >64k JSPs bombed).
Anyway, they had no real test environment but relied on a byzantine set of flags, logins, etc. to "test" in production. Being new and not used to the ropes, I nonetheless thought I knew what I was doing.
I was making a change to a Bill of Lading input page. I filled up a load with nonsense stuff like 50 barrels of beer and 10 containers of cats. Hit the button, eyeballed the change, said "yep, done".
Boss comes around the next day asking who had made a shipment request for beer and cats. I guess a truck had actually rolled around to the dist center to pick up this load; I guess the system lacked the "what" and just listed the quantities.
Whoops.
I was infamous for the beer and cats shipment for my entire time there, everyone conveniently forgetting the insanity of their staging environment setup.
TL;DR : Created a real shipment for 50 barrels of beer and 10 containers of cats
> everyone conveniently forgetting the insanity of their staging environment setup.
Same as in the famous "erased the production database" reddit thread, many companies prefer to shift the blame to the individual, failing to see their own faults.
Be humble. You're not the smartest dev in the room. I was guilty of this in my early career.
Related to this is realizing that most software degrades over time, being touched by many people under varying deadlines. Assume best intentions of your teammates until you _know_ there's a endemic problem.
Read code. Don't despair if you check out some cool OSS project and a lot of it is going over your head: pick another project or start consuming the code in small chunks.
Don't engage in bikeshedding.
Don't be an asshole.
Always be able to explain _why_ you: picked that solution, developed it that way, favor X over Y, etc. Explain your thinking.
The "right choice" is typically right at the time the decision was made; time will usually erode that "right choice" until it looks wrong.
If possible, document the reasons why critical/large decisions were made in the project/codebase (e.g. "we had to do this like X since system Y wasn't compatible with system Z at the time of writing").
Think of the next developer to touch your code. Think of you touching your code 8 months from the time of writing. Both will help you documenting the "whys" of your strategies if it may not be abundantly clear.
Follow coding conventions of everyone else at your company; don't try to buck the standards.
Don't be cynical. Don't be a source of constant negativity. Those people suck to work with.
Find programming forums/message boards and consume at least a few times a week.
Don't obsess over picking the "absolute right solution", pick the one that sucks the least given the information on-hand at the time. If it's a big choice, document why you made that choice.
Do not burn out. If your company commonly features "death march" projects, seriously consider leaving. I suffered a nervous breakdown around 5 years into my career by working 60-80 hour weeks for months on end while dealing with veiled threats about all our jobs. This was during an economic downturn and an especially hard time to find dev jobs, but I still think it would have been better in the long run to leave. I believe our company, knowing the tough local market for devs, intentionally grossly overpromised on a deadline to a huge customer because they knew many of us wouldn't have many options. I probably made less than minimum wage that year, never did the math.
Related: in many cases, the company is not loyal to you at all. Do not devalue yourself for loyalty to your company.
Always, always give credit where it's due. Never take credit for another's work or ideas.
One of the best things you can do for teammates is relieving them of stress and sharing the burdens; leave no one on your team behind (metaphorically). This obviously depends on how close-knit your team is, but there were many times I stayed late to help a close teammate with a production problem that technically I wasn't directly involved with. When they did the same for me, I was very thankful to have that other set of eyes, the person to discuss the problems out loud. I know together we solved those problems quicker, to boot.
Dang, really enjoying reading all these great recommendations; my podcast load is going to be growing (again)!
My personal faves out of my 100+ subs are below. All should be available through a typical podcatcher app. Tried to mark some as NSFW but probably missed some. Some of these are extremely well-known but the question didn't specify "hidden gems".
Part-Time Genius - General interesting stuff
James O'Brien's Mystery Hour - BBC radio program. People call in with questions and answers to (generally) interesting questions.
Stuff You Should Know - Interesting general topics
Irish and Celtic Music Podcast - Best celtic music podcast around IMO
Behind the Bastards - Profiles of evil or otherwise undesirable people/entities in history (NSFW)
Crazy Genius - Interesting topics, sponsored by The Atlantic
In Our Time - BBC 4 science show (very high quality IMO)
Business Wars - Multi-part series regarding company vs. company stories (Blockbuster vs. Netflix and Nintendo vs. Sega are my faves)
Something You Should Know - General info, tends toward self-help and lifehacks
Curiosity Podcast - Curiosity is one of my favorite apps (interesting topics every day) and these are short episodes
Freakonomics Radio - From the same author of Freakonomics
The Changelog - Tech stuff; recent episodes include "Segment’s transition back to a monorepo" and "Istio service mesh and microservices"
Ear Hustle - Interviews with death row inmates; oddly fascinating (NSFW)
Linux Unplugged - Linux stuff
Lexicon Valley - Interesting stories about language
We Hate Movies - Riffing on bad movies; I especially like it when they blast movies I actually like (NSFW)
Skeptoid - Stories for skeptics (of general antiscience etc)
More or Less: Behind the Statistics - BBC4 radio podcast, insight behind hard data
Linux Action Show - Linux stuff
Internet History Podcast - Really more of a 'tech history' podcast; recent eps include "History of Google", "The Epic Fall of Digg", and interviews with folks like CmdrTaco (Slashdot)
Oh No Ross and Carrie - One of my absolute favorites. They investigate pseudoscience and other stuff from the inside out. My absolute favorite series by them is their 9-parter on Scientology. If you're a Scientologist, ignore this recommendation.
Skeptic's Guide to the Universe - Pushing back on the pseudoscience
This Week in Enterprise Tech - Tech podcast; recent eps include "Bullying Black Hat" and "Unikernels and the Death of the Security Patch"
StarTalk - Neil Degrasse Tyson (usually) and occasionally Bill Nye
Mysterious Universe - OK, I generally consider myself mostly rational but can't deny I enjoy listening to "out there" stuff. This is one of the "out there" podcasts with two Australians
How Did This Get Made? - Funny podcast about bad movies (NSFW)
Thirty Twenty Ten - These guys provide a "this day in history" from 30/20/10 years ago. Typically covers pop culture, video games, etc.
Science Vs. - Another very well done science podcast
FLOSS Weekly - Free and open source topics
DogCast Radio - Dog stuff
The Curious Case of Rutherford and Fry - ANOTHER well-done science podcast from BBC Radio
Foot Stompin Free Scottish Music - Free Scottish music. If it's not Scottish, it's crap!
Late Night Last Week - Condenses all of the late night comedians. Host is kind of preachy and annoying, come for the content though (NSFW)
Dan Carlin's Hardcore History - Best history podcast on the planet
Seincast - Going through every Seinfeld episode; they've concluded their run now. Breaks down the minutia and trivia from each episode, each scene.
The Weirdest Thing I learned this Week
Disgraceland - Pods about wild musicians
Hello From The Magic Tavern - Guy falls through a
dimensional portal in a Burger King to the magical land of Foon. Radio-play style, I find this hilarious and well done.
Artificial Intelligence - Recent interviews with Christof Koch, Ray Kurzeil
Eddie Trunk Podcast - Interviews rock/metal musicians
To all readers who've never experienced it, working on a large Java (and other) codebases where the original developers completely overused patterns, your life will be hell in my opinion, just as much as a codebase written totally without thought or patterns.
Patterns can be useful but only in moderation and only with reason. They're spice.
Yep. I have no doubts than in such a situation my golden retriever would dive behind me...I love that little derpy bundle of love. Not that anyone expects a Golden to be a guard dog.
Anecdotal evidence: I'm a software architect/developer. The last three companies I've been with do not support remote work on a large scale because the IT Leadership did not want to fight against the managers of the departments who logistically _couldn't_ work from home.
Anecdotal, but I doubt I'm the only one where this is true, the mentality of "if we all can't do it no one can".
From the standpoint of CAP theorem, Consul is AP and ZK is CP. AP and CP distributed systems have their use cases, so it's important to think them through up-front. For example, I personally consider service discovery to favor AP.
I arrived at that personal assertion by building a SD setup using our conventions + Curator + ZK. In disaster scenarios we forced into the system when testing, I was able to get ZK to basically lock up because, really, that's what it's supposed to do, guarantee consistency--if it can't guarantee consistency, then it tells you about it. Consul for us fit the bill better.
Note: This was some time ago and I do not claim to be a ZK expert; it's quite possible the root issue was me. YMMV, etc etc.
This can be another service! You pay me some bitcoin to commit ID theft. I do it, create havok all up in your business. Voila! Damage done, now go and sue.
Money to be made all around on this deal.
Seriously, though, IANAL but I think you're right, I've read a couple other statements to that effect, that you'd have a hard time suing for the _potential_ for trouble. And would a judge require you to _prove_ an ID Theft was the result of the Equifax breach or just one of the other, smaller breaches?
Claude Skill for Java code straight from the essay