
Ask HN: What were the things you did that made the biggest impact at your work? - itsArtur
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.<p>For me, it was probably starting holding regular tech book review sessions.<p>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.
======
sn41
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.

~~~
inapis
IT in Indian Govt is stuck in 90s. Can't upload documents many times,
unncessarily strict restrictions (like images uploaded have to be 120x120 and
within 150 kb), the threats you mentioned AND the ABSOLUTE fetish with captcha
and OTPs

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!

~~~
Aperocky
That sounds like the (NC)DMV.. Of course, there are no risk of perjury (that I
know of), but if something goes wrong you'll be invited to stay in line for
another 4 hours.

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

~~~
jlokier
I lost Firefox sessions so many times last year! As I have a few thousand tabs
over several windows, some being placeholders for things I regard as
important, that sort of thing is really bothersome.

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.

~~~
Onawa
Good lord, what possible workflow leads you to having that many open tabs
without bookmarking them or using some other plugin that allows you better tab
management? Seems like a recipe for disaster, especially since you said you
end up having to dig through backups to restore state.

~~~
jml7c5
There's a middle-ground between bookmarks ("permanent" storage where it feels
like you're archiving the page), live tabs (obvious issues), and "to read"
lists (which are better for a stream of content that you know you want to read
but can't get to yet), that isn't served by current approaches. Firefox
Preview (Android) had a really good idea with "collections", where you
essentially save tabs into groups that were visible on the "new tab" page, but
it doesn't seem to have percolated to any of Mozilla's other browsers.

My painful tab overuse is caused by skimming HN/reddit a few times a day,
popping anything I'm interested in looking at into a background tab, then
getting to those tabs as I go through the day. It doesn't feel the Pile Of
Prospects should be in a "to read" list, as it seems that such a list should
only contain long articles & videos & etc that I'm certain I want to read but
don't have time for. That is, the "to read" list is meant to be something that
could be integrated with a tool like Pocket, where the content could be backed
up and read offline while in a continuous, focused state. Rather, the Pile Of
Prospects should go in a sort of "haven't looked at yet" list that needs to be
pruned and which is always visible so as not to go untended.

I'll probably write an extension to deal with my use case, but I think this
slow creep is how most people end up with a thousand tabs open.

I do agree that thousands of open tabs is a terrible way of operating. It's
not great for memory consumption (even with tab discarding), it makes hunting
through the "real" active set of tabs difficult, and people do end up losing
their Pile Of Prospects. I'd love to see Firefox et al gain better support for
this without needing to resort to extensions, especially as most extensions
designed for this are a touch too slow, have rough edges, or try to do too
much.

~~~
vs4vijay
Ditto, I do the same everyday. I once had ~700 tabs opened and I usually skim
through them in a 2 days to 1 week.

So I have enabled "Restore previous session" option in firefox and sometime I
manually crash the firefox so the next time I open the browser it asks to me
restore the 700+ tabs but they won't be consuming the memory because they are
inactive and when you click on them, then only it loads the contents and
consume memory.

This is how my tabs looks:
[https://snipboard.io/AUQ3kj.jpg](https://snipboard.io/AUQ3kj.jpg)

Also, I use multiple profiles of firefox and having them as separate
applications like this:
[https://snipboard.io/mXUCqp.jpg](https://snipboard.io/mXUCqp.jpg)

PS: I don't use chrome or electron based apps as they are memory hogger.

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

~~~
volkk
how can you tell they're attentive?

~~~
muzani
You can tell by body language normally. There's a kind of look when someone is
off thinking about other things, and there's another kind of look when they're
listening to every word.

------
javajosh
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. :(

~~~
maest
What are your main objections to BTD loops? Also, which alternatives do you
suggest?

~~~
steev
My main objection is it dramatically decreases your productivity. If building
and testing takes 5-10mins (which is the case in our codebase) trying to fix a
bug can take forever when you aren't exactly sure what the cause is. You don't
want to try multiple fixes simultaneously because if something doesn't work
you aren't sure which of the fixes (if any) might be causing the issue.

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?

~~~
Aeolun
I would have less time to legitimately read Hackernews!

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

~~~
jwcrux
You’d love _The Unicorn Project_ if you haven’t read it. I highly recommend
it, and it’s a story around roughly the same journey.

[https://www.amazon.com/Unicorn-Project-Developers-
Disruption...](https://www.amazon.com/Unicorn-Project-Developers-Disruption-
Thriving-ebook/dp/B07QT9QR41/ref=nodl_)

~~~
kqr
And/or anything related to the state of devops report. Nicole Forsgren et al.
are doing amazing work in observational science around this.

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.

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

~~~
vidanay
For user facing documentation, always ask Karen in accounting to read through
it and provide her opinion.

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

~~~
mmcconnell1618
I was laid off early in my career despite being one of the top performers and
getting rewards and kudos along the way. It opened my eyes to the fact that no
job is a "safe" job and you should think of a salaried position as an open-
ended contract that happens to pay out every two weeks.

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.

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

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

~~~
desc
This.

When something needs doing, I just get it done. If you wait for everyone to
agree that it needs planning to be done at some point in the future, it'll
never get done because the feature firehose never relents.

This has cost me a few weekends, but a) it meant that I kept my sanity in the
long run and b) despite said fixes reducing the company's dependency on me
(ie. supposedly damaged the job security) taking the initiative has allowed me
to demonstrate a different and entirely more significant kind of value.

~~~
WalterBright
Indeed, doing successful rogue projects enhances your job security.
Unsuccessful ones, though, watch out!

~~~
desc
Yes, that's why these cost me a few weekends... if it's done in my Free
Time(TM) they don't have to know about the unsuccessful ones.

~~~
kqr
I'm sure this works fine for you, but I would in general _not_ recommend that
people do work on their spare time. The reason to do that is, as you point
out, that you get to take all the risk, and your company gets all the profit.
That's not, generally, a healthy employment relationship and as an employer, I
would be pissed if I found out someone did that.

Just carve out an hour every day from your salaried time to chip away at these
projects. Nobody will ever know unless you tell them.

~~~
therealdrag0
Eh. The effect could be the same. I average less than 8 hour work days. But
once every 2 months or so I throw myself at a problem at work I personally fee
strongly about. This might spill into a late-night or weekend. But I like the
rush of it and I get a lot of appreciation at work and it has materially
benefited my career. Once I even got an on the spot bonus issues from the CTO
for fixing a perf problem.

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

~~~
BossingAround
"Don't call yourself a programmer" \-
[https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
programmer/?HN_20140807) (2011)

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

~~~
JustAPerson
For anyone curious about using something like this technique, Facebook has a
similar tool.

[https://github.com/facebookincubator/BOLT](https://github.com/facebookincubator/BOLT)

~~~
bertr4nd
Yes! In fact that’s from the same team I was working on at the time (HHVM). My
tool predated BOLT by a few years, I think. Obviously BOLT is way more
sophisticated and does an even better job.

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

~~~
masonhensley
> opportunity to write new tools for front line support staff

Any learnings you could share on success factors / features in the new
internal tools?

~~~
geocrasher
I work in the web hosting industry, and front line folks often struggle with
some Linux commands- grepping logs etc. So I built automated tools that
generate reports based on search criteria. I know that's terribly vague,
sorry. I also simplified an existing tool to produce less but more valuable
output. They've gone over well so far.

------
gingerlime
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](https://3.basecamp-help.com/article/35-the-six-week-cycle)

~~~
jacobr
Sort of did this at my previous job by being senior and in a good position and
communicating that I’d be working from home first 1, then 2, then 3 days a
week. Other team members with long commutes followed (it made sense to avoid
in-person meetings the days I wasn’t there, so then other devs would also
wfh..) and the company invested in better tech, software and processes for
remote working. Talked with a former colleague who is now 4 days a week remote
- when I started he spent 3h/day in the car.

------
debrice
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

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

~~~
quickthrower2
One hit wonder - thanks I’ll introduce this concept to my boss and see if it
helps us: we accidentally lost some caching due to a bug but there was no
measured performance penalty on our production performance tests. Hence we
didn’t notice until someone looked at the code. Could be a one hit wonder!
It’s a nice concept to think about in any caching code.

------
Ididntdothis
“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

~~~
martincmartin
Suppose you were to come upon someone in the woods working feverishly to saw
down a tree.

“What are you doing?” you ask.

“Can’t you see?” comes the impatient reply. “I’m sawing down this tree.”

“You look exhausted!” you exclaim. “How long have you been at it?”

“Over five hours,” he returns, “and I’m beat! This is hard work.”

“Well, why don’t you take a break for a few minutes and sharpen that saw?” you
inquire. “I’m sure it would go a lot faster.”

“I don’t have time to sharpen the saw,” the man says emphatically. “I’m too
busy sawing!”

\-- The 7th habit of "The 7 Habits of Highly Effective People."

~~~
sethammons
Quick! No time to get in the car, hurry up and push!

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

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

------
notyourday
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](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.

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

~~~
kqr
What were the critical, actionable metrics?

~~~
mitefinedailes
At first, it was only for developers, actionable metrics were: number of red
CI jobs, distribution of build times (especially 90th, 99th percentiles),
number of open pull requests.

Now each team has their own dashboard. E.g support team shows a graph of
open/assigned/outstanding tickets, with SLA breaches highlighted. Sales team
shows a sum up of data anomalies in their CRM (missing data, inconsistent
states).

The rationale is that anything that shows up in red needs immediate action
from a human being to avoid blocking the team, and we strive for the right
balance between always green and always red (which are both useless states).

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

~~~
bathtub365
Why do you stay if you are compromising your values on a daily basis?

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

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

------
jbn
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](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.

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

~~~
cellularmitosis
Setting aside your own time for learning and your own agenda is so crucial.
The sad reality is that most orgs which run on a ticket/sprint process will
make room for nothing outside of tickets.

Looking back at my previous gig, the biggest mistake we consistently made (but
were somehow impotent to correct), was assuming that all of the “we should”’s
which came out of post-mortems or brainstorming sessions would somehow get
done. In reality, if it doesn’t become a ticket, it won’t get done.

Here’s the rub: in many orgs, there is simply too much resistance to getting
engineering-centric tickets injected into a product-owned ticket pipeline.
They are either outright rejected, or deprioritized to the point of being a
“soft no”.

If you are in this situation, my advice is to take a risk and simply stop
asking for permission to do the self-development and engineering-centric tasks
which you think are important. Set aside regular time for yourself (without
asking for it), track your own private backlog, and just do it.

This was the biggest change in my ability to deliver impact: realizing that I
wouldn’t be given permission to get these things accomplished, and would have
to bear the risk myself and just do it.

Worst-case scenario, this won’t be tolerated and you’ll be fired. Good.

~~~
kqr
This is very insightful. The higher the level you want to perform on, the more
responsibility you have to bear yourself. Asking for permission is really
asking for someone else to take the risk, the blame, and therefore the
responsibility. That only works up to a point, and you will have to get used
to shouldering more and more responsibility on your own initiative to truly
get anywhere.

~~~
Stronico
Asking someone else to take a risk is a very good insight.

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

------
maddynator
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

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

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

~~~
zaphod4prez
I would LOVE to hear a little more about this & anything you've learned about
making these meetings effective. Would love to know how long do they last, how
many ppl are in the meeting usually (wondering what the "right size" is), or
if you got that idea from somewhere?

~~~
khalilravanna
Where the idea came from: one of our engineers Will Seitz suggested it. I'm
not 100% sure where he got it from. I absolutely love it though and have been
a big proponent since the first one.

How long do they last: 30 minutes on Tuesdays and Thursday

How many people: 4 when we started, up to like 10-12 now. I think the right
size is like 6-8 maybe. We're approaching critical mass where we either need
to add a lot of process or splinter it into separate groups with a good ratio
of experienced to less-experienced people.

General musings: We have a separate one for the frontend and the backend each.
We started with the frontend one and that's the one I've run and iterated on
the process of. The basic structure is just go over the commits from the past
2 days (since we do it Tues/Thurs). You have to rely on the person running the
meeting to 1) know what's important to spend extra time on and 2) keep the
meeting rolling along through the meaty, important commits. This requires a
decent amount of knowledge in the domain area as well as some good sense of
the pulse for what's being worked on across different teams so they know when
to surface things that would be important for cross-communication. That and
even having a sense for good mentoring opportunities (e.g. people keep having
trouble with `async/await` so I'll call out this commit with really good
examples of using that feature).

So, all and all, the person leading it is one of the most important things.
Having a good culture that's open to healthy constructive feedback is super
helpful and allows you to dive into some conversations ripe with growth
opportunities. It's one of my favorite things we do at our company!

~~~
zaphod4prez
Thank you, that's so helpful! This is a really great idea

------
TeMPOraL
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](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...](https://old.reddit.com/r/Common_Lisp/comments/et0fx1/temporaltracer_tracing_profiler_for_common_lisp/ffddyvm/).
I was supposed to blog about it, but couldn't find the time this week.)

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

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

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

~~~
Ididntdothis
I bought a huge whiteboard and mounted it with my boss one evening breaking
facilities regulations. It’s used a lot and facilities stopped grumbling after
a while.

~~~
ferver
invaluable tools -- a computer needs a stack, a human needs a pad

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

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

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

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

~~~
quickthrower2
A good manager will try to get their team to “just do it” and take initiative.
They shouldn’t need to be like an orchestra conductor. The team should be like
a Jazz band.

~~~
k__
Some people simply have to make a name for themselves

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

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

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

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

~~~
wool_gather
If you'd care to share more details about this test, I, and I'm sure others,
would be interested!

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

------
cushychicken
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...](https://www.adafruit.com/product/368?gclid=Cj0KCQiA4NTxBRDxARIsAHyp6gBPb23rsGud9Y0lZtYcS3tKmxuwliSXBDi5UwcBnLVqibwHTMl5FAgaAtg1EALw_wcB))
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.

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

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

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

------
not_the_nsa
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](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.

------
defnotashton2
* 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

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

------
sys_64738
Resigning.

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

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

~~~
broth
This is an interesting idea. How are these emails generally received? Do you
have a template[0] that you follow?

[0]:
[https://github.com/kbariotis/templates](https://github.com/kbariotis/templates)

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

~~~
dundercoder
I volunteer to ask the stupid questions sometimes to make it ok for others to.
It has really helped, and as a bonus, no one really thinks I’m stupid.

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

~~~
disposedtrolley
That’s a fantastic idea. In my last job I started a weekly newsletter of
curated tech articles, but this crowdsourced approach sounds far more
sustainable.

> My manager had a game-changing suggestion, too: give phonetool icons for
> people who submit to the list

What’s a phonetool icon?

~~~
duck
I believe that is their portal/intranet. Each employee has profile there and
these would be badges for that area.

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

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

------
nikivi
100% Discovering and using Karabiner.

[https://medium.com/@nikitavoloboev/karabiner-god-
mode-7407a5...](https://medium.com/@nikitavoloboev/karabiner-god-
mode-7407a5ddc8f6)

~~~
noir_lord
As someone who recently switched from Fedora to OSX for work reasons this
looks _amazing_.

------
code-is-code
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

~~~
tbrock
How though? All of the swagger open-api tooling is REALLY bad or abandonware.
Did you write your own?

~~~
kqr
I can't speak for the GP but the way I've dealt with that is by using the tiny
subset of tooling that isn't really bad, and supplementing it with some custom
patches to make it also work.

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

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

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

------
arez
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

~~~
sethammons
The anonymous questions for all hands is a problem at our company. We used to
have it and some people abused it. Instead of asking hard questions, one or
more people used it to attack. "Why is so-and-so even here? They are utterly
incapable and a fucking idiot." Or "how can leadership be so stupid?". A
couple of bad apple comments came up each all hands so leadership changed it
to not be anonymous. We lost out on other great questions, I'm sure, and also
lost the toxic ones. People do ask hard questions tied to their names, but I'm
sure we are losing other needed questions due to the policy.

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

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

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

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

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

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

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

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

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

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

------
mmcconnell1618
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?

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

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

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

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

~~~
kjksf
Could you share the name of that tool?

~~~
forgotmypw
It's just a couple of shell scripts:

[https://github.com/potomak/screencapture](https://github.com/potomak/screencapture)
(not mine)

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

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

Know your tools. Know your environment.

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

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

------
segmondy
Documentation

Automation

------
tehlike
Promoting experimentation and rapid deployment.

------
marvinblum
Quitting.

------
orasis
Getting enough sleep.

------
fnord77
got treated for attention deficit, pi

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

------
f0ok
Quitting.

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

~~~
war1025
I don't understand this. Care to elaborate?

~~~
Mike8435
He means developers should commit work in progress directly to the master
branch. The work in progress would be disabled in production deployments by a
"feature flag" boolean configuration setting. The exception to this rule would
be very large changes which must be developed in a separate branch, and have
been carefully planned with a corresponding RFC document.

In general I don't like this approach. Branches are troublesome when you hire
mediocre developers who don't communicate and coordinate between each other.
Merge conflicts are often a result of laziness, poor architecture and
planning, and weak communication skills. In my experience, smart developers do
not create problems with feature branches.

~~~
desc
I agree with this. One of the best changes we ever made was embracing a
branch-heavy merge-centric workflow for _literally everything_. There was
considerable pushback initially because it was perceived as 'complicated' but
that dried up after a month because people were no longer fighting to push
their hurriedly-rebased work to the canonical master branch any more.

It also means we can put an extra layer of QA testing between dev branch and
master, which works nicely as a means of forcing communication between devs
and QA too, and helps with onboarding (because the product featureset is
_huge_ ).

Automated tests are great, but having a person read the feature ticket
description and testing steps and then check that the functionality actually
_makes sense_ before it hits the master branch...

One more tool in the box, and it's a great culture correction mechanism too.
Devs who don't test their work before submitting it get it sent back for
fixing and feel less productive, so doing things thoroughly the first time
feels quicker than rushing it. Doesn't even require management to monitor
rates of reopening tickets, etc: people just don't like having to redo things.

