Ask HN: What were the things you did that made the biggest impact at your work?

Designing more forgiving interfaces.

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.

Mmmh... I rewrote big chunks of Firefox's Session Restore to ensure that people stopped losing their data in case of crashes. Pretty big impact on both Firefox and, hopefully, the life of a few hundred million users.

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 :)

Calling on quiet (but attentive) members of my team to speak up in meetings where we need to make a decision.

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.

Three things: voting down a move to microservices, identifying a fundamental flaw in a core data-structure that is the high-level impetus for future refactorings, and encouraging people to be discontent with multi-minute long build-test-debug (BTD) loop.

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 worked for a company that had gone from selling on premise software to cloud, and going from build to production release took a while. Realistically you could expect 1-2 days if everything went well. This was definitely not problem #1 at the company but I really wanted to push to see how much time we could shave off. I got some like-minded teammates to put time into a new release pipeline process, and we built some nice integrations where you could control the release process & see results from inside of slack.

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.

Writing accessible documentation.

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.

Though this is probably not what you're asking for...

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.

I changed a boring linear telemarketing script into a flow chart (with lots of clever jokes in it) that instructed the marketeer to thank people and terminate the conversation slightly prematurely. (in stead of trying to force people though the linear script) The mood in the call center changed from wanting to die to perpetual laughter. It seemed to increase productivity slightly but people called back years later when they needed insurance.

Taking the initiative in doing the right thing. For example, when I worked at Data I/O, their LogicPak communicated via a serial line. This required a terminal emulator on the IBM PC side, and there were various ones of erratic quality available for the customers.

I just decided to write a simple VT-100 terminal emulator for the PC in assembler as a rogue project. It worked out so well Data I/O included it with every LogicPak for many years, as then the customer had everything they needed in the box, and Data I/O didn't have to support emulators they had no control over.

I am reminded of patio11's article "Don't call yourself a programmer".

I would say this comment section should be renamed "Don't make a big impact at work without clearly getting the credit for the value added"

Before you do any more impactful things at work to benefit someone else's equity, do the following

- set up an internal blog location where you can write up, each friday, what you and your team have achieved

- add simple videos of good stuff in action (screen casting is easy now and always stick your voice track on top)

- tell people, with links.

Stake your claim.

I wrote a little tool that used perf profiles from our production fleet to generate a custom linker script that reordered our main server program’s binary to be significantly more cache friendly. The heuristic I came up with for reordering was one of the few (maybe the only) genuine “eureka” moments I’ve had in my career.

And the performance win was extremely nice :-)

At my current employer I have done two things that I think have had a big impact. I didn't do them alone, and in some cases, I couldn't have done them alone.

The first was to root out a customer-blaming culture that had festered for far too long in the company. I recognized how toxic it was, and how bad it was for customer service, when I arrived. Not long after that I became a supervisor and my manager (also a new hire) and I agreed it was really bad. I worked at my end and he worked at his end, helping those who would change to change, and giving those who wouldn't the opportunity to find new work. It wasn't easy. Part of it was for me to write a couple of hours of customer service training material and deliver it to all new hires. That led to me becoming the company's trainer, and I get to weave it all together in a 2 week orientation and training for all new hires.

The second thing I've done is create documentation where it didn't exist and have cleaned up documentation that was messy. I took 25-30 disparate articles on one subject, weeded out the stuff that was irrelevant or deprecated, put it all into two clear documents, and called it a run book. It went over really well and helped the department who depended on it.

Lastly, I've also had the opportunity to write new tools for front line support staff and rewrite old ones, and create documentation and training regarding their use.

In the end, I write and talk for a living, all to the end of making it easier to provide great customer service in our sector (web hosting). I love it.

Switching my company to remote. It was a gradual process but it worked and now we’re fully remote and everybody seems happy with no exceptions.

I can’t take full credit but we also switched to doing 6 week project cycles[0] and pitches inspired by Basecamp.

[0] https://3.basecamp-help.com/article/35-the-six-week-cycle

Sounds very silly and minimal but I've learned to say "no" and it changed my whole work life. I've gained so much out of it.

- respect of my opinion

- peace (as opposed to stress)

- Massive code quality increase

- Meet my deadline more often

and probably more... this was life changing

I played a really small role when looking at some caching data for a system another team run (their logs are ingested and processed by us) and noticed that a lot of the time the content requested is only requested once - this is sometimes referred to as a "one hit wonder"

Once I told them this and showed them some graphs etc they did an experiment to set it to only cache on the 2nd hit, and this reduced the write rate on the disks massively - potentially increasing their lifespan quite significantly (saving money)

They did the hardwork of engineering it, experimenting etc but I'm proud that my little contribution helped drive a real change in a domain outside my team :)

“For me, it was probably starting holding regular tech book review sessions.”

How did you do these so people actually participated? My company is very deadline driven so people don’t really care about learning. Every attempt at regular learning meetings quickly died because people feel they don’t have time. Do you have a specific format?

I have led regular meetings about coding style in another company. These went pretty well but in the current company I have failed at instilling curiosity for learning things for its own sake

I was the fifth employee of our now-acquired startup. Being in that early amplifies a lot of decisions, both good and bad. The contributions I’m most proud of and still are practiced/referenced today are:

- I was the one-person support for a while, and created our support process, user guides, etc. Any way that I could automate the process to speed up response time and free myself up to do other small tidbits of work, I tried.

- I was the one-person QA team, and documented known corner cases, golden paths, feature-specific regression testing guides, etc. When another employee began helping with QA, it made it much easier to onboard them to the process. We’ve since hired someone to build test automation programs and they’re referencing the same guides that are years-old now to guide their automated tests. I thought that was pretty cool.

Unconference - a meeting twice in a month where anyone from team present on any topics except controversial topics like politics. This helped everyone to learn completely different things

Initiatives: More and more initiatives and idea discussion - because of this everyone started thinking everyday to build innovation and became adaptable to take risk.

Two things:

1. I embraced that Perfection is a mortal enemy of It Works. Our customers pay us for it to work now, not be perfect at some point in future.

This allowed us to save millions of dollars a month and made us a viable going concern.

2. "Mongodb is Webscale" - https://www.youtube.com/watch?v=b2F-DItXtZs

We aren't Google. We don't have Google-level global problems that we need to solve. Anything below Google level can be solved using boring technologies that just work.

This allowed us to significantly and rapidly improve customer experience.

Convincing the team that always-on dashboards with critical, actionable metrics would improve release rates and uptime.

Making sure that upcoming new features and achievements are showcased to the whole company through weekly demos.

I found out my co worker had high interest loans from life and a coding bootcamp. So I gave him an interest free loan (around 20k).

Then I realized how my other teammates also have bad loans. Planning to sell my RSUs when I get them and give out interest free loans to my coworkers.

I don’t see any other way to make an impact at work because we are building privacy invading products and I think my best efforts at work actually brings negative impact to society. Hopefully if my coworkers are no longer held down by financial woes they’ll be able to stand up for what is right and I won’t feel so alone.

I am no longer with this company, but it was a small web dev company that had a problem with insecure legacy code on just about all 200 of its clients.

I wrote a software firewall to prevent the exploitation of these insecure websites as well as a monitoring system to identify any websites that got compromised in other ways.

It moved us from spending 80% of our time recovering endlessly defaced websites to 5%, pushed us on to newer and bigger projects, and made several hackers and at least one pen tester actively curse the systems in their exploit code.

The three major things I did was automate everything, document everything and require justification in every task I do.

Whenever I had a task that recurred more than once, the second reoccurrence was when I implemented automation of that task. Didn't matter what it was or how much time it actually saved. The purpose was to have documented, reproducible results on any task I do. I often switched roles and then a year or two later I suddenly had to perform an old task I was "really efficient at." With automation i was able to do the task right away with almost no need to jog my memory.

Documentation requires you to get in the habit of writing. Doesn't have to be good, doesn't have to be smart and color coded. You just have to do it. I have vimwiki setup to a git repo and every discussion, every meeting, every project or note I took ends up here. Searching is easy enough and I don't have to worry about losing anything.

The last one deals with people so it requires tact. Whenever I'm asked to do a job that is a one off of something else or has additional work attached to it, I ask what the justification for the added engineering time would be. The point is to make me available for as much development as possible so if I'm stuck doing things that aren't actually needed it wastes resources. It also reduces complexity as there are minimal special cases for things.

Two things come to mind:

1/ carefully rearranging headers in a large C++ product, cutting build time from hours to 30 minutes. Think levelization a la Viega (see https://www.youtube.com/watch?v=QjFpKJ8Xx78).

2/ setting up JSP->java->class compilation to detect syntax errors at build time rather than at web server startup, eliminated finding such errors in the field completely.

1. Setting aside a "20% day" to develop infrastructure - I went through a slow period about 15 years ago where I had the option of doing this without meaningful tradeoffs and I built some software that I still use to this day. It's tempting to call this a learning, or reading day but I've found that I lose focus if I have a full day to do that - if you decide that you will spend 8 consecutive hours building a personal infrastructure tool (what ever that winds up being) you will have something to show for it at the end of the day - and therefore you will do it again. Those sort of things build upon each other nicely. Tooling/infrastucture is a marathon.

2. Set aside 30-60 minutes a day for learning, however you define it - for me it's PluralSight and Anki - that is usually how I start my day. Having it on the calendar, without many options to choose from makes it very efficient. Learning should be in sprints.

3. Set aside some amount of money every month for tools and capital purchases - targeted savings accounts are perfect for this - having the money in an account targeted for this purpose instead of a general account prevents a lot of money anxiety and allows you to do a better cost-benefit analysis.

How timely! Just this week, I was able to bring together our client's large IT team with my agency's large team of engineers in a shared Slack, after nearly a year and a half of our only communications being through email and (lots of) ad hoc Skype calls.

My vision driving what has been a many-month push to get our teams together is to build a much higher degree of trust, respect, and collaboration between the teams of engineers, to enable our program team (consisting of both the client's team and our agency's team) to more nimbly plan and triage issues together, and to mitigate email grenades that unnecessarily pull in business stakeholders who, without context, see only bits and pieces and (understandably) fear the worst.

The combining of the teams is obviously still early in the experiment and there's a lot of history we are going to need to overcome together, but I'm optimistic this will be one of the simplest but most effective strategic moves I'll have made in my career up to this point. I'm excited about the future (challenges and all) for the team and will be doing everything in my power to make sure everyone is supported and building the trust necessary in any high-performance team.

Blocking my calendar. My calendar has become Swiss cheesed. Filled with meetings with 30 mins-1 hours gaps. Couldn’t focus to write code or architect or read or review code.

Decided to block the calendar. Everyday from 12:30-4:30 pm my calendar is blocked and slacked is muted. If anyone had emergency, they are able to call me. Haven’t received a single call in 5 months. Wrote tons of code and spending time learning

In my previous job I introduced automated tests. This was over time taken up by other developers too. At one point the automated tests prevented a broken build from being shipped which made them quite popular.

Mine is actually very similar to OP’s! I think regular discussion of code is such an impactful tool in an engineering organization.

I think as a manager it’s often the small things that can have the biggest impact. At my current company I helped revive a meeting we have called Code Read. It’s basically a meeting where the engineers sit down and go over the commits from the last couple of days focusing on ones that implement something novel or are a good learning opportunity for other devs. Sometimes it’s as simple as “what’s DRY” or “what’s a decorator” and other times it’s a deeper discussion like the performance impact of switching to immutable data structures.

It’s been especially impactful because I also pushed for us to hire some junior engineers and it’s been a wonderful way for them to get exposed to a lot of great lessons and feedback outside of the PRs they already have. Since then, those engineers have all come into their own and some of them are becoming heavy hitters.

1) Calling out the bullshit. Sometimes politely, sometimes firmly, but when things didn't add up, I'd call them out. Eventually I've uncovered a piece of a product that not only didn't yield correct results, but was unrescuable in principle. As a result, I ended up prototyping and then leading the design and development efforts on a new version that did things right, which eventually became a very strong part of the product offering.

(It later turned out that way before I joined, some other people also called the big problem out, but were overruled by someone high up, and after that everyone kind of forgotten that there was a problem in the first place.)

2) At my last job, I wrote a tracing profiler for Common Lisp - or rather, a quick and crude pile of hacks resembling a tracing profiler, now available here: https://github.com/TeMPOraL/tracer. Up until then, we had a sense that our performance problems came from the database, but having a hard time pinning them down with regular profiling, we blamed them on the database driver (that we've written ourselves). When we started using the tracing profiler, we quickly discovered that the driver itself was perfectly fine - it's the amount, shape and structure of the queries we're doing that caused our performance to suffer death by a thousand cuts. That couple hours of detour into writing the profiler paid for itself in the following week with an order-of-magnitude performance increase, and the insights gained shaped the further refactoring and redesigning efforts.

(Some more details about the profiler here: https://old.reddit.com/r/Common_Lisp/comments/et0fx1/tempora.... I was supposed to blog about it, but couldn't find the time this week.)

Honestly, just being careful and catching mistakes. On almost every project I've worked on, I've found a few. When things get big enough, what's the chance that there's not some mistake? Just reviewing through things carefully, with a fresh set of eyes, can often get a few of them.

Sounds really lame in comparison to everyone else in this thread. Added freakin’ prettier, a lot of resistance and concerns when I brought the idea up in the first place, but time has proven there had been no more BS debates every meeting about how Alex wants trailing commas and Bob doesn’t agree.

Having two dry erase boards with various colored fine tip markers on hand

I worked in an old non-tech LargeCorp IT department for a year and the most impactful decision was simply giving a damn about things. Everything was so abandoned that it was hard to break the inertia. I started trying to care about the warnings thrown by the compiler, and eventually managed to upgrade the internal apps to be able to work on IE8 instead of 6, and from them moving to IE11 was simpler, and afterwards everything was working on Chrome and modern browsers, which in turn allowed some coworkers to push to moving up from Win XP, and eventually by the time I left the inertia had turned into forward moving improvements. Felt really proud about that and left in good terms.

Being vocal about problems when others try to ignore them. I wasn’t popular for it at the time, but I gained respect from the people who matter. The result was averting many bad situations. This both required, but also built up my self confidence.

It often seems like shutting down potential acquisitions has the biggest impact, but it’s hard to get credit for saying “no” to something.

I stopped waiting for people to tell me what to do.

There are too many aspiring managers out there that just don't have anything subtantial to say.

Building a single webpage which submitted search forms to the different ticket systems and web based tools at the company.

Multiple usages:

Enter one keyword, and look it up in Wiki, Redmine, two extra ticket systems, mails with customers with fewer clicks.

Or enter a customername, and find him in any if these systems using other search forms.

Also offering short links to often used functions, like selfhosted password generator etc.

Saved me lots of clicks and copy and paste when debugging or investigating issues. The company had >1000 customers, product was an ecommerce software based on php/mysql

Received a small bonus when the bosses found out. I do not know if my former collegues still use it, I left the company.

One minor thing: Recently, I uncovered that around 5% of the legacy code I was using was based on the wrong Date variable starting from its SQL pull. One of the variables was EnteredDate and another was EffectiveDate, I kept getting duplications using EnteredDate , so I dug around the organization and found someone who said "Oh, I always use EffectiveDate".

I had to re-run models and tables, the faulty code was an important variable-builder for my multivariate logistic regression models, so I needed it to be 100% accurate.

Not me, but our director of BI did the following. He created a email list of anyone with an analyst title. Every other week, he takes recent changes to our warehouse (eg. new business-facing datasets, fixes to ETL problems, etc) and writes a news letter about those changes. He includes simple SQL to show what's new or what's changed.

It has had an incredible impact on usability of the warehouse from the business's point of view. Also a really interesting take on what business friendly documentation looks like.

Interview process. From the start, we did away with whiteboard questions and instead opted for a take home test. The test wouldn't take more than an hour or two, depending on how much effort the candidate wanted to put into it. They got 2-3 weeks to complete it, with the help of the internet.

Because the test was specially designed to weed out people that didn't know how computers/compilers worked, it was surprisingly effective at removing 90% of candidates. The people that got in were of the highest quality.

Related question: What did you do that had the biggest impact, but wasn't recognized by such by the organization?

For example, speed up the build might make people more productive, but in a way that's not obvious to management, or even to the people working on it. It might be seen as a nice thing, but relatively minor. The knock on effects -- releasing more often, which leads to being able to try more experiments in production -- might not be noticed.

Man, I know exactly what I did that helped this, and it's so dumb, but I know it's made a difference.

We build consumer electronics, and typically, early on in the process, we find some sort of bug with our power supply designs that generally requires a bunch of people surrender their power supply PCBs to the designer. I didn't do a damn thing to fix the power supplies, but I did manage to find [these great connectors](https://www.adafruit.com/product/368?gclid=Cj0KCQiA4NTxBRDxA...) on Adafruit that people can use to power their systems using any barrel jack wall wart supply. All you gotta do is solder some wires and choose a wall wart with the right voltage/power rating.

Sure, it's not a to-spec power supply, and it typically can't play audio at max volume, but that's irrelevant - most of the new functionality that needs to be implemented has to be implemented in software, by software developers who just need access to the tiny computer in our products. Not a high power application - at least, not much more than your average router. (Which, incidentally, almost all have wall wart supplies.)

Plus, since they're barrel jacks, they're easy as hell to unplug if you need to get a hardware rework done.

Saved us a ton of time designing stupid, bespoke, one-off AC/DC supply harnesses to suspend line voltage electronics. Just get yourself a nice safe wall wart and go. Plus, I love that I'm helping funnel a bunch of bigco bucks to Adafruit, who's a company I love to support.

Hiring someone that handles my flaws. I'm really good at handling messiness and chaos, I can think big picture/long term but I really suck with details and organization.

I hired someone who is super detail focused and he's been amazing. He keeps meeting notes, tracks conversations, random suggestions and for funzies fixes my messy code.

I'd say this has had a huge impact on my own work, not necessarily for the larger team.

Considering a large portion of the people I meet at company all hands are thanking me for it, git-cinnabar, a git remote helper that allows to access Mercurial repositories and has decent performance for the Mozilla codebase compared to alternatives (to the exclusion of Mercurial proper).

Ironically, it's a tool I wrote and maintain by sheer selfishness (I grew sick of Mercurial), on my spare time.

As a developer/manager thing: reading, learning to fully listen to someone until they are done, understanding that you want people to ask questions DURING your presentation, creating and enforcing a code review process, evangelizing unit tests, and REALLY caring and making sure that whatever I did actually worked and solved the right problems. Also, saying no.

I work in a state govt department. Very simple infrastructure additions have paid out majorly for us. It's my job to innovate around research infrastructure, so the following should be read as outcomes of my role, not bragging.

I migrated my division from Word docs on shared drives to Atlassian Confluence Wikis, which made knowledge more discoverable amd accessible.

For a work group, I set up a CKAN data catalogue. Soon after, our division adopted it, and after demonstrating it at a GovHack hackathon, I got seconded to our sister agency to build the first production version of https://data.wa.gov.au.

For a statewide turtle monitoring program, I switched out paper-based data capture with electronic data capture using OpenDataKit. We now have real-time data analysis and reporting. Many colleagues have found a similar need for electronic data capture. Claim to fame: wrote an R package `ruODK` to facilitate data access from ODK to R.

* implemented a more difficult rigorous screening test and process for new hire canidates

* reduced build times. Boss was angry at me spending time on it and it did take a while but after we started shipping weekly instead of quarterly...

* ignore my boss anytime he gets annoyed I automated legacy things. It bit me in the ass once, but paid out 10x several times.

* internal tools and automation scripts

Teaching tech concepts to non-technical people and visa versa.

I think a lot of the tensions that often exists between people from different backgrounds, especially when deadlines and budgets are tight, is lack of understanding what the other person is doing, what their job is.

So I started doing little talks and workshops around topics like, web applications, databases, what the different components of the system are and how they interact with each other, different types of "bugs", computational complexity, etc.

While, most of these weren't directly applicable to those peoples daily work, it helped them understand a bit better why for example task A takes much longer than B, although from a laypersons perspective they look the same. Also people appreciate learning new things when broken down to the appropriate level and removal of jargon.

Similarly I let interested tech people learn about things such as UX, product development, marketing, finance, legal, etc.

Resigning.

I decided that as QA, I was going to own our end user's experience, and not worry so much about which team was responsible for what.

That is, when I'd find an issue that needed fixing or monitoring, the dev's on different teams would argue about the contract. "Well it's their fault because they change the webservice, so they should have tests." Etc. The hot potato would be passed and nothing would get done by any team.

I was like, screw that, I just want it to work. So as much as I could, I'd set up monitoring tools and tests to make sure our stuff worked, rather than waiting for it to break and doing a long song and dance about how it "isn't our responsibility."

Users loved my work and I became known as the go-to person if you actually needed a problem solved, rather than argued over.

Emailing “Dave’s week in review” every Friday afternoon, to a distribution of everyone I have ever met professionally. The email summarizes what I did that week, both professionally and personally. Every week I hear from someone I know, as a result of the email. Many opportunities have resulted.

Encouraging others to ask questions. Forcing myself to ask in meetings as an example even though the questions look "stupid". It's uncomfortable but we've mitigated several implementation mistakes over the years. This sounds like truism but still rarely happen in practice.

While at Amazon, I started a mailing list that sends one curated software engineering tip each day. It still persists, last I heard.

While working there I noticed that other people did productivity hacks I didn't know, and vice versa, all the time, so I created the mailing list. Others had created tip lists before, but they had just posted their own tips on it, and their list fizzled after a few months.

My list had impact because it wasn't "my list" - I just set up a discussion list and a template, and send in the first forty tips or so. After that, it was essentially all other people's tips. My manager had a game-changing suggestion, too: give phonetool icons for people who submit to the list. It served as both motivation and advertising.

"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."

Yes, it bothers me to no end seeing code that has been developed using 20 different mental models. I like the idea that enterprises (seemingly) are trying to scale by providing tools to individuals rather than trying to build up hierarchical structure within teams, but in my experience this has caused a radical redirection to having almost no cohesiveness in how code is constructed. "We use Spring Boot" is not a magic bullet.

Convinced entire team on spa and microservice infrastructure, it made total sense for our company. Pushed for totally new tech in company and actually made it happen 6 months later. This was very fulfilling and now its norm.

100% Discovering and using Karabiner.

https://medium.com/@nikitavoloboev/karabiner-god-mode-7407a5...

Doing API-first.

Start with defining the swagger.json Then generate:

- frontend-typings

- frontend request services

- backend routes and DTOs

- database fields

- use angular-jsonform for forms

- use the swagger for frontend validation

- use the swagger for backend validation

- use the swagger to discuss api changes with the client

This saves half of developing time and prevents 90% of your bugs

I made improvements to my previous company’s front end deploy system. One would simply create a Github PR and the build system would make a commit based link that would show a staged version of the code. This meant as part of doing a code review, the reviewer can also play with a live running version of the code and do a user experience review / find bugs too.

That’s how I want to setup the CI/CD pipeline for my new startup boomadmin. Creating a PR automatically creates the docker images and frontend assets to serve a staging env per commit.

Pushing to master deploys the images to prod.

Implementing an end to end testing framework on a badly written although heavily relied upon production system whose quality was getting steadily worse over time. It arrested and reversed the decline in quality.

My experience is that often the lowest effort changes also have some of the biggest impacts. I work in consulting, and I think one of my largest impacts has been to create a pre-engagement checklist for one of our very common engagements and then getting our team to review the checklist with clients ahead of time. It took maybe a day to get the first version out, and cuts ~1-2 weeks off of our projects.

Unexpected downstream effect, this had a big enough impact that other groups started creating checklists for other kinds of scenarios.

developed a tool together with a colleague that ket anyone ask anonymous questions to the founders. We had the problem, that the founders wanted to get more people to ask questions in our all-hands meetings and me and my colleague thought it might be that a lot of people are afraid to ask them in front of a big crowd. So we created an easy to where anyone can submit questions anonymously and everyone can up and downvote them. We're both not working at the company anymore, but the tool is still used for 3years

I'm early in my career, but something that I did recently that seemed to have an impact was to encourage people, both tech and non-tech, to voice what they actually want, regardless of whether that thing seemed possible, and to then work with the group to walk back from there to something possible and reasonable. Prior to that point, everybody was in the habit of just not wanting anything that didn't seem immediately doable.

I created a notification gateway for services, jobs, and users to utilize. It accepts plain-text to send to a default channel or custom if the text contains a valid channel spec. It also accepts HTTP requests where the headers can control nearly every aspect of the message (channel, name, icon, etc). It's one of the simplest things I've written, but it's impact to level of communication is jarringly large.

Exposed key events happening in the product as an anonymized feed in a dedicated Slack channel, where each event links back to the CRM, a support profile, and a log of the session. (Only those with appropriate access can actually use the links.)

Strung together Segment, Zapier, customer.io to make it possible.

It’s ridiculously useful, and also gave others ideas for other types of feeds we can have for smaller teams.

I built an open source library that made our API easy to use. It ended up being a deciding factor between us and competitors for some customers.

The library itself was built with a lower-level part that covered every single feature, and a higher-level part that covered the most common use-cases, including enough to build a nice demo app with it.

I developed a router automation framework tailored towards my team’s usecases. I then used that to setup a nightly regression suite that runs on a live router and collects code coverage information (metrics heh).

More recently, I worked on improving/refactoring the bundle (link aggregation) implementation for the upcoming Cisco 8000 router.

Focusing on integrity, reasonable expectations, decreasing entitlement. Stop being reliant on excitement and emotional highs to get work done. Don’t check email/slack until after lunch. Be intentional of what you do as much as possible. Give myself over to the process and forget about FOMO.

I wrote a little web app to track my weekly goals and check-in with a couple of friends/colleagues: https://weeklycheckins.com/

It's only been online for a few weeks but it's already been quite helpful.

Insisting that we have design reviews every week with designers, engineers, and relevant stakeholders. Now when designs get to engineers for implementation or to product managers for acceptance, there is much lower churn.

Besides just writing and designing software:

Developed and upheld a process for writing requirement documents for software development with my team mate.

Started to do scrum master'ish role.

Wrote a tool to manage our (really custom) development environment.

I asked my manager what we should stop doing. What things are not contributing to our goals as a team? What can we outsource because it is commodity work that doesn't create value for our organization?

The obvious answer to this question is often increasing gross sales through design improvements. Also, finding correlations with data can also be extremely helpful.

One of the best processes I've done for a few different teams is a "tech scrum" which is basically lean coffee but just for my tech team.

If you by impact you mean noticeable, then often the things having the biggest impact on people and systems efficiency are also the less visible ones.

I found a simple and light screencapture tool and I record my coding sessions into reasonably-sized videos.

I wrote a book in our niche (search), which seems to have done a lot to help our small consulting firm.

Saved a million four in a little under a minute with a SQL query last year.

Know your tools. Know your environment.

Instead of arguing about product changes, created a framework to A/B test them.

Staying home (from an "open office" design) and working there.

Documentation

Automation

Promoting experimentation and rapid deployment.

Quitting.

Getting enough sleep.

got treated for attention deficit, pi

I don't think any of the below are too exciting, but the effects they have probably show up in the bottom line:

- I invested a lot of time into speeding up our customer-oriented websites after I noticed we were regularly loading in 4-10 seconds. It wasn't seen as a major priority - however, past a certain load time for each page, you start losing users. We started off way past that certain load time and managed to end up at something between 1 and 3-second loads in most cases.

- This wasn't my idea, but a marketing manager I respect a lot once mentioned that people were spending a huge amount of time filling their date of birth while signing up. Something like 30 seconds or more. The reason was that we had been using a date picker that defaulted to the current year, so people would have to click back i.e. 30 times to select their year of birth. On his request, I replaced it with 3 lined-up fields of selects, and the time spent on average went down to 2 seconds.

- I had the chance to do a major rewrite of some legacy systems that worked fine, but weren't built to scale and lacked standardization - the company had a few hundred users in one country when they were made, and when I worked on it there was a locally-modified copy of the system for each country we were in.

The reason for it was that some of our integrations would cease to work due to third parties, and we had to implement a major upgrade, so I built a service to handle requests and standardized the old servers to only make requests to the service without being smart about how they're processed.

In the process, since everything was liable to break anyway if I didn't get it right, I updated every dependency (whether it was for the code or the server) that I could find. Not fixing what wasn't broken was a value that had served us up to that point, but we were racking on technical debt and it was a good chance to get rid of it. Sure, lots of things -did- break, but solutions were found. Technically, it'll help both me and future devs entering the project, and practically, since the integration chiefly targeted contract processing for our customers, the fact that we can still do contracts and nothing broke on the surface is a success.

- I implemented log aggregation across all our servers (using ELK) and it's been helping us track errors and server states a lot. We could have used something like Sentry, but we have millions of events going through on a regular basis, so it's cost-effective.

- We use an internal time tracker that works based on office card access events. I was always curious about racked up overtime, so I added in a calculation for it in the API and returned it in the response when loading a user's info without adding it to the frontend. I mostly used it for myself and told a few colleagues about where to look if they wanted to check. A few months later, overtime calculation was added into the tracker as a feature.

Quitting.

Ban pull requests if they aren't a big change resulting from a RFC.

Therefore most feature code should be shipped to master with feature flags.