The challenge is, in a real org of some size, you’ll suddenly get marketing or customer success asking you for commitments that are very far out, because ad slots have to be booked or a very large customer renewal is coming up.
And some of the normal coping mechanism (beta-branch that spins off stable feature to the general release branch) don’t work for all those requests.
Try as you might, you are going to get far off deadlines that you have to work towards. Not for everything but for more than you’d like.
The stupidly easy solution is to just give them stuff that has already been successfully delivered to production to market, 9 months from now. There’s invariably a huge backlog of years worth of successes that marketing wasn’t even aware of.
Yeah, I agree that might work if the marketing team isn’t that connected to the product. I’ve not worked with a marketing team where that would work, but maybe it will for some. It doesn’t change the “massive customer will only renew if” scenario, though.
I’ve not worked with a marketing team where that would work, but maybe it will for some.
I’ve never been anywhere that I thought it would work, but it ultimately did, almost everywhere.
I’ve found it takes a few iterations, but the marketing folks in on it love being the ones who actually can reliably deliver on their promises.
It doesn’t work for the marketers that promise whatever they please without talking to dev, but I don’t find them to be worthwhile professional allies, so I don’t sweat it.
It doesn’t change the “massive customer will only renew if” scenario, though.
Very true. It doesn’t help with that case, and that one does happen. I’ve had the best luck saying “we don’t do that, but we’re scrambling to add it” in that situation.
i know this is for the lols, but you'd be surprised how often stuff like this happens... bodge wires and dead bugging it are much cheaper than re-spinning a board/IC. anything to get the boss off your back, just make sure to give your technicians a case of beer/beverage of choice for the extra effort fixing your fuck up.
Nah. It doesn’t say not to plan. It says to prefer responding to change over planning. Which means both happen but responding to change is more crucial. Or put another way don’t let your plan get in the way of responding to change.
I’m sure you were being sarcastic, but I get kind of tired of the Agile strawman and people shitting on it. It’s not a complex philosophy yet people extrapolate so much (too much) and then get annoyed when their assumptions don’t pan out well. even performing sprints is an extrapolation, so this meme gets it wrong too.
TBF bugs are arthropods too, unless you’re the kind of person that includes snails and slugs and/or earth worms. Certainly, “true bugs” in the entomological sense are. Centipedes, along with millipedes and a couple less-known classes, are myriapods, which are a member of the arthropod phylum along with other subphylums like hexapods (insects and friends), arachnids, and the various crustaceans. Arthropods themselves are panarthropods, a group which includes a couple arthropod-looking phylums, namely the velvet worms and the tardigrades/water bears.
Tin the wire and the pin first and then touch the iron to them both quickly. They should stick fairly well without needing to add additional solder. Also, like someone else mentioned, flux can help quite a bit. (Maybe even a cupped soldering iron tip might be useful, depending on the situation.)
Learning how to solder SMD components will get you extremely familiar with how solder behaves at that scale. Let’s just say it’s significantly different than just doing basic wires and THT.
(Well, the solder doesn’t really act different, but at smaller scales it looks like it does.)
I tried to hand-solder a Hirose .35-pitch connector onto a custom OSHPark board once. Let’s just say it was a humbling experience. Thanks to a generous friend, I learned the value of solder masks and owning a home reflow oven.
Respect to whoever can do this sort of thing, but life is too damn short and my eyesight and hands don’t need the abuse.
I can’t pinpoint the exact problem, but corporate agile destroyed software development for me. I completely lost the fun developing software as an employee. I had the most fun on my first project, which was a waterfall one.
The problem is that people realized that they could sell agile training to middle management if they changed it to be about making middle managers feel empowered and giving progress visibility to upper management.
Agile has some good principles, but too often projects are delayed to support the process, when the process exists to support the projects. When a team is more focused on stand-ups and burn down charts than they are on shipping software, then they’re no longer agile. Unfortunately that is what happens to a lot of teams that decide to use Agile.
2-3 sprints?! Y’all really flying by the seat of your pants out here huh?
My teammates and I have no trouble planning multiple quarters in advance. If something crops up like some company wide security initiative, or an impactful bug needing fixed, etc then the related work is planned and then gets inserted ahead of some of the previously planned things and that’s fine because we’re “agile”.
I delivered a thing at the end of Q3 when we planned to deliver at the start of Q3? Nobody is surprised because when the interruptions came leadership had to choose which things get pushed back.
I love it. I get clear expectations set in regards to both the “when” and the “what”, and every delay/reprioritization that isn’t just someone slacking was chosen by management.
I think this may be less about Agile and more that you have a great management team that sets clear priorities and goals. Not every Agile environment is like that.
I do greatly appreciate my management and general company tech culture, they’re great.
I agree with your stance here, because it’s part of my point. I tend to see more people bitching about Agile itself and not management or their particular implementation.
The jobs where I was only given enough info to plan 2 - 4 weeks out were so stressful because I frequently felt like I was guessing at which work was important or even actually relevant. Hated it.
Turns out it’s a skill issue ;p (on the management level to be clear). Folks, don’t let your lazy managers ruin you on a system that can be perfectly fine if done right.
It’s not bad, it’s just not agile. Agile exists for projects where that simply isn’t possible. Its sacrificing a bit of potential best-case productivity to ensure you don’t get worst-case productivity.
if I’m leading a project, I avoid this by begging POs to give me a sprint 0 where i solo code out all the scaffolding ground work before all the other engineers join the project.
I thought about doing that, but I don’t have the training or license to drive a boat. I’m in Hawaii, so it can get pretty rough out in the ocean. I’m also not sure how I would get money for food and stuff. I don’t have massive savings or anything.
Same haha. But i use a combination of commits ( but not pushed ), ammending, fixups and usually clean it up before making a PR or pushing ( and rebase/merge main branch while at it). Its how git should be used…
The s “squash” command is where we see the true utility of rebase. Squash allows you to specify which commits you want to merge into the previous commits. This is what enables a “clean history.” During rebase playback, Git will execute the specified rebase command for each commit. In the case of squash commits, Git will open your configured text editor and prompt to combine the specified commit messages. This entire process can be visualized as follows:
Note that the commits modified with a rebase command have a different ID than either of the original commits. Commits marked with pick will have a new ID if the previous commits have been rewritten.
You can also amend for a softer approach, which works better if you don’t push to remote after every commit.
The git commit --amend command is a convenient way to modify the most recent commit. It lets you combine staged changes with the previous commit instead of creating an entirely new commit. It can also be used to simply edit the previous commit message without changing its snapshot. But, amending does not just alter the most recent commit, it replaces it entirely, meaning the amended commit will be a new entity with its own ref. To Git, it will look like a brand new commit, which is visualized with an asterisk (*) in the diagram below.
You can keep amending commits and creating more chunky and meaningful ones in an incremental way. Think of it as converting baby steps into an adult step.
Or if you want to --force commit 😈. Imo if it’s my own working feature branch on a trunk-based roll-forward repo idgaf about rewriting history, and I will do it with wanton abandon.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.