It could be a tool that you have created, a process that you have started or anything else which created a big and lasting impact on your workplace.
For me, it was probably starting holding regular tech book review sessions.
Over time the discussion around both architecture and implementation details got way more structured, quicker and more satisfying to all parties. Seems obvious, but building up mental model of software development through a structured approach is better than just letting it happen naturally during work hours.
I work in the public sector in India. Usually forms here are phrased in threatening terms - you can submit any document only once, and there is a threat of perjury for just uploading the wrong document etc. I proposed that we can utilise cheap cloud storage so that users can submit documents as many times as they want, and as long as any of the uploaded documents are correct, then it will be accepted.
This reduced the phone calls our office received by about 80 percent.
I hope the Indian govt sets up something similar to that design/tech agency set up by US/UK govts.
In the meantime, a lot of props to you for designing interfaces that empathize with users. That's the kind of thoughtfullness we need!
No, they're saying call volume went down by 80%. We know nothing about how many callers generated the calls before and after. Maybe each and every customer used to call them 5 times per month, and now each customer calls them only once per month. That would be an 80% reduction in calls, but a 0% reduction in # customers who feel the need to call.
I rewrote the Firefox Shutdown so that it actually worked.
I also introduced structured async programming, async testing, async exception reporting in our codebase.
And yes, I do enjoy bragging :)
Every so often, after a system restart due to running out of battery on my laptop, I'd start Firefox and get the dreaded "only one window, home tab".
I was able to recover by going through backups, but it was a fiddly and manual process, and for a while last summer it happened annoyingly often. There were a couple of times I couldn't recover what I'd been working on the previous day.
I'd sugges you need to find an alternative workflow... even one thousand tabs has far passed the point of diminished returns
The other one is that getting file safety correctly is really hard. The OS likes to the developer, the filesystem lies to the OS and the hardware lies to everyone. For most applications, that's not a big deal, but for something that used to run every 15 seconds on hundreds of millions of computers, this can cause data loss. That's why you really want to use a DBMS rather than roll your own format if data safety is critical.
For shutdown, it was also a case of initial architecture not matching the current situation anymore. Firefox was initially a synchronous, single-threaded, single-process architecture, but this had stopped being the case for a few years already. At some point, shutdown needed to be re-architectured, I happened to be the one who managed to convince people that the time was now :)
For example, when a Garmin watch runs out of battery during workout (or if a software crashes), the workout always gets saved, and you can resume it when you turn the watch back on.
There will be a pause in the conversation and (as if its my meeting) I'll say something like generic "Jim what do you think?" No matter what he says I acknowledge it and thank him.
A few things happen. 1. It removes the internal conflict Jim was having if he should speak up or not. 2. It gives him 'the floor' so he knows for a minute he will be heard. Others are probably wondering why I called on him and want to hear what he has to say. 3. His answer might not be directly related, however it often sets off a chain of conversation that often does lead to creative answers.
People actually do like to contribute. The way I look at it is we're not leaving this room until I feel like we have at least heard every idea good or bad. Those set of ideas are our collective intelligence at that moment and I fully intend on leveraging it.
https://youtu.be/9jhPm_2WYH8
24:00
As an introvert in a team of very talkative and opinionated people it is often hard to speak up. Having other people creating space for me to speak has been very helpful.
Unfortunately, I find very long BTD loops to be personally offensive though, to the point it makes me emotional, which harms my ability to make my case. Despite knowing this, it's almost impossible to stop it from coloring my arguments. I fear that I have such a large amount of contempt for those who don't share my view on this that it leaks out whatever I do. I even know, intellectually, that this is wrong - ignorance does not deserve contempt, but compassion, after all. But my traitor heart doesn't want to listen. :(
I don't know how true / substantial this effect is, obviously. Nonetheless, seems like good self awareness shown in this comment. That's more than a lot of people can say
Alternatively, I'd like to work for an organization that's on the same page here. Effectiveness in software (or anything that depends on iterating on a design) relies more on a fast loop than anything; I'm tired of fighting this battle.
It can be annoying, but at the same time, it forces them to take a break to think about things they're currently working on. When you have nothing to think about and your current work is simple and you're waiting minutes, you tend to get bored and frustrated though.
And also remember that some people would simply rather get paid to do nothing, and a long BTD cycle helps that.
Encountering these in my very first programming job made me learn make(1).
The thing is, I'm not very bright and my work "style" involves a fair share of trial and error. Obviously, all this waiting prevented me from doing my thing, so I eventually rewrote the whole build system just so I can do more trial-and-error.
I've always considered my dependency on a fast BTD loop a weakness, though. I guess the majority of developers can just imagine what the code does in their head and only make the changes when they know what they're doing.
You should try writing software for SP routers :)
When was this, and how does it look now?
Having come off of a project that supported 400k registered and 100k active users on a single server, this project isn't yet at that scale and they were anticipating massive scale issues. This mistake was a real bonanza for an engineering team wanting to learn the latest tech; a massive failure for the product that really needs fast UX iterations to succeed.
If you want to talk more about it, you can email me.
And yet some organizations want to run all the linters, all the tests, for all the languages, orchestrated by Jenkins on a huge Amazon cluster. This is bad.
[1] This is very cool - an Apple IIe emulator running Logo in the browser. https://www.scullinsteel.com/apple2/#logo
[2] Inventing on Principle has improving the BTD loop at its core https://vimeo.com/36579366
Maybe a different way to look at it is: if you could shorten the BTD loop to a minute or two, why _wouldn't_ you want that?
The ole eyebrow started twitching when I read this. I once had a 6 month contract with a RoR shop where they had such bad performance issues they started developing in production mode so it wouldn't reload everything constantly. This allowed you to make some changes quickly, but 90% of everything required you to restart the web server and it literally took minutes for it to load everything. They had close to 200 rubygems, and I've always guessed that was the core of the issue.
When I suggested we need to fix that issue, the senior did-an-internship-here-last-summer developer got extremely passive aggressive with me (I didn't renew that contract). This guy thought he was amazing, I remember him arguing with me about a bug where they were storing decimal numbers as float in MySQL. I seriously had a 30 minute long conversation where he told me repeatedly I was wrong until I finally got exasperated, made the changes, and it fixed the bug. The guy was couldn't believe it fixed the issue and spent another couple of hours looking for why I was wrong.
I've never touched RoR again, that experience was horrific.
Sometimes you can't help the slowness, but I know I seriously dislike header-only libraries in C++ specifically because of their effect on the BTD loop. I have no idea how people can tolerate working like that, it's a slow hell for me.
So there were 2 kinds of big categories of things that happened. One was that we really slashed the amount of time from first master branch build to deployment. If things went well we could release to production in under an hour. This radically changed everything about our process. We started building smaller stuff because we could try things out in production very quickly. Code review times dropped a lot because we had smaller units of code. Planning meetings went faster because we were talking about smaller things so discussions didn’t go sideways. The team seemed to really like it.
Second class of thing that happened was that people from other teams would drop by our slack channel and see us rolling out code by talking/clicking to a bot, and they’d want to know more. And then we’d show the speed improvements and how it integrated into the rest of the prod architecture so that you could make the migration to using it too. So it kinda organically became the defacto release architecture at the company over time.
I’m a little bummed out now because it was super fun to see this all go down, it was almost accidentally the most far-reaching change I’ve instigated at work and the impact was great.
https://www.amazon.com/Unicorn-Project-Developers-Disruption...
The gist of it is that reducing your time-to-production is one of the best investments you can make. It changes everything about how you build things.
[EDIT] to be clear, quick painful dangerous releases are no better, and (pretty much necessarily) come with the same pain in onboarding, jumping between repos/projects, undocumented "oh sometimes you have to re-install that to get it going" works-on-my-machine bullshit, getting a good feedback loop going, et c.
Dead Comment
Most people either write no docs or they write a doc that assumes the reader already knows what the thing is.
I write docs that assume you're a new employee and explain the thing in simple, plain English before building up the technical details.
Notably, these kind of docs make it easy to handoff maintenance and further development to someone else so you can move on to new projects.
Realizing that my career is my own, and that I owe nothing to anybody. Nobody is doing _you_ a favor by hiring you. At most, it's a calculated risk.
Furthermore, realizing that I shouldn't suffer for management decisions. If you've been putting out fires for a whole year, either the whole team has been consistently doing a very poor job (unlikely, though possible), or the fault is out of your reach (quite likely IMO). In either case, it's totally acceptable to jump the ship to another team.
A company only keeps you around if they can justify getting more value from you than what they are paying to keep you around. Add more value and document that value you're creating for job security.