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

[arturw8i]

It could be a tool that you have created, a process that you have started or anything else which created a big and lasting impact on your workplace.

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

Over time the discussion around both architecture and implementation details got way more structured, quicker and more satisfying to all parties. Seems obvious, but building up mental model of software development through a structured approach is better than just letting it happen naturally during work hours.

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

[billfruit]

Not to mention the usage to blinking and moving marquee text to convey important information.

[john-radio]

It sounds like you also deserve credit for measuring the 80% improvement in call volume and using it to show the value of the change. That is how you make shit happen; respect.

[Aperocky]

That's amazing, kudos to you, I imagine it's difficult to pull this change? Are there political consideration that a line of command must all answer to?

[sn41]

No, you just have to overcome inertia. There are legal considerations for multiple uploads - who decides which document is valid etc. But once the policy is clearly vetted and publicly stated, the courts are usually fine with it.

[muzani]

Amazing. I've avoided work in the public sector because I thought I wouldn't accomplish anything. But this is a great example of how to be impactful in such a job.

[phaemon]

That is superb. What you're really saying is that 80% of your customers no longer feel the need to phone you.

[rahimnathwani]

"What you're really saying is that 80% of your customers no longer feel the need to phone you."

No, they're saying call volume went down by 80%. We know nothing about how many callers generated the calls before and after. Maybe each and every customer used to call them 5 times per month, and now each customer calls them only once per month. That would be an 80% reduction in calls, but a 0% reduction in # customers who feel the need to call.

[r0rshrk]

Holy shit ! This is super interesting ! I'm in India and always wondered why this happens. Have you written more about it somewhere else ?

[sn41]

No...unfortunately the details are confidential. But I wish there was a way to exchange best practices within the government agencies so that this sort of mechanism becomes widespread.

[asdko13roasi]

How much did it increase the workload and manual error rates of the reviewer for having to check multiple documents?

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

[rayuela]

This has saved my ass more than I can count. You've earned your bragging rights

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

[jlokier]

You answered it yourself - they play the role of bookmarks.

If you were to tell me to use bookmarks instead of tabs, I'd find that weird: Bookmarks are like a less useful version of tabs. I used to use Bookmarks and found them less useful; it's that simple.

Yes, I do use a plugin that allows better tab management, thanks.

With regard to digging through backups: Bookmarks would have exactly the same problem if they got wiped, would they not.

UPDATE: I'm with jml7c5's comment: There is a middle ground betweem traditional Bookmark use (archived) and live (current issues). My open tabs occupy this middle ground as a kind of medium-term, time-ordered backlog of issues to take another look through when time permits.

Some of them are articles containing information I want to extract to notes, some of them contain specific technical bugs, solutions or discoveries I need to incorporate having found out about them, and generally many serve as useful reminders about some issue or other to get to in due course.

The ability to visually see their time and association structure that grew passively is quite useful, as is the ability to visually see the actual content at a glance, because that helps me remember why that content is in my queue.

Bookmarks are almost useless for this. The URL is not enough by far. If Bookmarks had large thumbnails, retained scroll position, and it was possible to highlight particular text, then Bookmarks would be much more useful for my needs.

No doubt there are various clipping tools such as Evernote that would serve me better. But I haven't found an open source one that hits the spot, and I'm not interested in using any closed source or cloud-based clipping tool, having been bitten by locked away formats, and inability to extend the tool, too many times already.

[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

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

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

[kqr]

Some people use tabs as a sort of bookmarking/selective history thing. Firefox makes this especially easy with tree-style tabs. I'm still undecided whether it's good or bad.

[travisjungroth]

It’s terrible! Do you leave every single piece food and cooking utensil you own out on the kitchen counter at the same time? No, cause it’s a workspace and that obviously makes no sense. Tabs are an ephemeral system that you can clean with a single mouse click. If there’s anything in your life you should be able to keep tidy, that’s it.

[jlokier]

Perhaps you're proposing to put all the kitchen utensils in the garbage and go shopping for new ones each time you cook; that's surely even weirder!

If you're proposing that bookmarks are the equivalent of tidy drawers (and a tidy mind), then I wonder, why you think tabs are not.

In Firefox, Bookmarks and Tabs seem quite similar apart from the UI for handling them. However Bookmarks record only the page title and URL, and organising them is so much work that picking up a group of tasks with them is a pain. Whereas Tabs record where you were on the page as well (scroll position), and automatically product a track of grouped, time-ordered tasks that were spawned, which can then be pruned.

(Neither is ideal; I would like to be able to highlight text on a page or a region, to attach a note to remind me what task I've set the page aside to resume later, and to have a fast, sleek UI for reorganising later in a pruning phase. Neither Bookmarks or Tabs provide these things unfortunately, and neither does any extension I've tried so far.)

When a comment above asks what sort of workflow, my answer is that at least there is a workflow. Bookmark land is where tasks go to die because too much context is lost, and not enough is captured automatically.

[hazz99]

Different people use tabs in different ways. Tree style tabs lend themselves to having a larger number of more permanent ones.

[notyourwork]

You can decide how to live your life, others can decide for themselves. No judgement needed.

[c0restraint]

> As I have a few thousand tabs over several windows

I'd sugges you need to find an alternative workflow... even one thousand tabs has far passed the point of diminished returns

[drywater]

Why do you think they weren't working so good in the first place? I mean, why was a bad solution implemented in an open-source product?

[Yoric]

For Session Restore, there were two problems. One of them was that it had gained lots of features and the architecture wasn't adapted anymore. That's the kind of things that happens with all long-lived projects.

The other one is that getting file safety correctly is really hard. The OS likes to the developer, the filesystem lies to the OS and the hardware lies to everyone. For most applications, that's not a big deal, but for something that used to run every 15 seconds on hundreds of millions of computers, this can cause data loss. That's why you really want to use a DBMS rather than roll your own format if data safety is critical.

For shutdown, it was also a case of initial architecture not matching the current situation anymore. Firefox was initially a synchronous, single-threaded, single-process architecture, but this had stopped being the case for a few years already. At some point, shutdown needed to be re-architectured, I happened to be the one who managed to convince people that the time was now :)

[ignoramous]

In my time writing databases, I found that not only the mount-flags could result in data-loss despite fsync, given you use fsync as it is supposed to be used [0], but even enterprise-grade hardware would at times (at that scale [1]) drop and/or corrupt a few bits here and there.

That reminds me of the case where AWS famously revealed that a single NIC in their ginaromous S3 fleet flipped a single bit once in a while and that caused an outage because their gossip-daemon responsible for fleet health-checks failed spectacularly [2].

Bryan Cantrill's talk on the realted topic of hardware/firmware bugs is pretty good [3].

[0] https://danluu.com/fsyncgate/

[1] https://perspectives.mvdirona.com/2017/04/at-scale-rare-even...

[2] https://youtube.com/watch?v=swQbA4zub20&t=46m02s

[3] https://youtube.com/watch?v=fE2KDzZaxvE

[nbaksalyar]

That's a feature I sorely missed after the demise of the original (pre-Blink) Opera Browser, and one of the reasons I strongly prefer Firefox over Chrome. Thank you so much for this!

[tomaskafka]

This! I love the companies that care.

For example, when a Garmin watch runs out of battery during workout (or if a software crashes), the workout always gets saved, and you can resume it when you turn the watch back on.

[bberrry]

As a firefoxer and tab-hoarder, with more than 200+ open as I write this, thank you!

[kingludite]

Oh, thanks!

[codesuki]

Thank you!

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

[lastpost93]

Coincidentally, there’s an interview with Tim Cook where he mentions this exact concept when asked about leadership.

https://youtu.be/9jhPm_2WYH8

24:00

[reinkaos]

Thanks for that. I'm one of the "Jims" of the world and one of my superiors started doing that to me recently.

As an introvert in a team of very talkative and opinionated people it is often hard to speak up. Having other people creating space for me to speak has been very helpful.

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

[thomk]

It's obvious they are listening to what is going on. They aren't looking at screens or doodling. My rule is if in you are in my meeting: you should be there and are a valuable member of a team, so let's see what you think.

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

[np_tedious]

> it makes me emotional, which harms my ability to make my case.

I don't know how true / substantial this effect is, obviously. Nonetheless, seems like good self awareness shown in this comment. That's more than a lot of people can say

[javajosh]

Thanks, but undeserved. Self-awareness may be good eventually, but sometimes it just makes you feel like a helpless observer to your own actions. I think you need more than just awareness - you need to practice feeling the feelings and not acting on them in the usual way. That's the part that will yield results, I hope.

Alternatively, I'd like to work for an organization that's on the same page here. Effectiveness in software (or anything that depends on iterating on a design) relies more on a fast loop than anything; I'm tired of fighting this battle.

[alvarosevilla95]

Awareness may not be sufficient, but it's most definitely necessary. You at least recognized a problem, and want to find a solution, even if you haven't found one yet or even tried.

[vsareto]

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

It can be annoying, but at the same time, it forces them to take a break to think about things they're currently working on. When you have nothing to think about and your current work is simple and you're waiting minutes, you tend to get bored and frustrated though.

And also remember that some people would simply rather get paid to do nothing, and a long BTD cycle helps that.

[tayo42]

Idk if it forces someone to take a break. If I get forced into a long compile. Maybe even 30 seconds I might pull out my phone and 5 minutes later.. Oh its done..

[_TwoFinger]

> I find very long BTD loops to be personally offensive though

Encountering these in my very first programming job made me learn make(1).

The thing is, I'm not very bright and my work "style" involves a fair share of trial and error. Obviously, all this waiting prevented me from doing my thing, so I eventually rewrote the whole build system just so I can do more trial-and-error.

I've always considered my dependency on a fast BTD loop a weakness, though. I guess the majority of developers can just imagine what the code does in their head and only make the changes when they know what they're doing.

[celticmusic]

it's not a weakness, it's productive. Anyone writing a lot of code without testing it is doing things in a subpar manner. This isn't about intelligence.

[Cyph0n]

> multi-minute long build-test-debug loop

You should try writing software for SP routers :)

[nojvek]

I feel you. First thing I do is setup some form of hot reloading. In my last workplace we want from half a minute to <5 seconds of dev loop iteration. It’s a night/day difference.

[insomniacity]

I'd be interested to hear more voting down microservices. The title didn't actually specify, but I assume you felt it had a positive impact? :)

When was this, and how does it look now?

[javajosh]

Yes, I felt it had a positive impact. The system was already over-engineered for its purpose, something virtually every senior would admit if pressed. uServices would only add to that administrative overhead at design time, and massive operational complexity at runtime.

Having come off of a project that supported 400k registered and 100k active users on a single server, this project isn't yet at that scale and they were anticipating massive scale issues. This mistake was a real bonanza for an engineering team wanting to learn the latest tech; a massive failure for the product that really needs fast UX iterations to succeed.

If you want to talk more about it, you can email me.

[bcrosby95]

And if you design your monolith carefully enough you might be able to horizontally scale too.

Back in the late 00s we horizontally scaled a monolithic project with 5mil daily users and another 8mil daily users. Peak was 10k and 15k requests/sec of dynamic per-user webpages.

The hardest part was the databases. Our solution was standard for the time but pretty ugly nowadays: sharding MySQL by user id along with heavy use of memcached.

Would have killed for some of the modern scalable databases. Sometimes I wonder if some people using microservices are chasing challenges since much of the actually necessary hard parts are already figured out.

[maest]

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

[javajosh]

Software development is the BTD loop; you can't eliminate it. I got my start with Logo[1], which has an amazing BTD loop! People like Bret Victor[2] have talked at length about it (although Victor doesn't use that term, IIRC). Even the trend toward "notebook programming" - Jupyter, Observable, etc are really about shortening that loop. A major reason to use an IDE is to potentially shorten the BTD loop. Lots and lots of tools exist specifically to shorten this loop.

And yet some organizations want to run all the linters, all the tests, for all the languages, orchestrated by Jenkins on a huge Amazon cluster. This is bad.

[1] This is very cool - an Apple IIe emulator running Logo in the browser. https://www.scullinsteel.com/apple2/#logo

[2] Inventing on Principle has improving the BTD loop at its core https://vimeo.com/36579366

[Aperocky]

Well, I don't see how linters/test on a final cluster is bad. This is why we have unit/integration/alpha/canary tests. The first 1 can happen on my laptop over 5 seconds while the second can happen on my personal instance over 20 minutes. Usually first means the second will pass and I just need to run it in the background without breaking any workflows.

i.e. It might not be a bad feedback loop, you just need more of them that are faster.

[celticmusic]

5 seconds is already painful, the point of the other poster is to delay that stuff until the end. When the BTD loop is long it's a looooooot harder to get into the flow, and you have difficult really thinking about the problem.

Imagine trying to read a novel but after every paragraph you had to stop and wait for 5-10 seconds.

[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!

[hoten]

My first job, the BTD loop was at least an hour. This was 2015.

[MereInterest]

Not OP, but I share the same dislike. Note that he said that he is against long BTD loops, not BTD loops in general. If it takes more than 5 minutes to get more information about a problem, my mind will wander. I'll check email, read up on conference proceedings, etc. If it takes 15 seconds to get more information, then I can keep focus on the current problem, add the new information, and iterate appropriately.

[celticmusic]

> and encouraging people to be discontent with multi-minute long build-test-debug (BTD) loop.

The ole eyebrow started twitching when I read this. I once had a 6 month contract with a RoR shop where they had such bad performance issues they started developing in production mode so it wouldn't reload everything constantly. This allowed you to make some changes quickly, but 90% of everything required you to restart the web server and it literally took minutes for it to load everything. They had close to 200 rubygems, and I've always guessed that was the core of the issue.

When I suggested we need to fix that issue, the senior did-an-internship-here-last-summer developer got extremely passive aggressive with me (I didn't renew that contract). This guy thought he was amazing, I remember him arguing with me about a bug where they were storing decimal numbers as float in MySQL. I seriously had a 30 minute long conversation where he told me repeatedly I was wrong until I finally got exasperated, made the changes, and it fixed the bug. The guy was couldn't believe it fixed the issue and spent another couple of hours looking for why I was wrong.

I've never touched RoR again, that experience was horrific.

Sometimes you can't help the slowness, but I know I seriously dislike header-only libraries in C++ specifically because of their effect on the BTD loop. I have no idea how people can tolerate working like that, it's a slow hell for me.

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

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

[baroomba]

I think the harm done by long, painful, dangerous releases and complex onboarding or different experiences and expectations for how to effectively test and get a good dev feedback loop going in various components of a system (usually these things occur together, because the same things that cause the latter also cause the painful, slow, dangerous releases) is badly under-accounted for. It murders agility yet companies wander their way into it in the name of agility then don't ever fix it because the fix is slow and dangerous since everything is slow and dangerous.

[EDIT] to be clear, quick painful dangerous releases are no better, and (pretty much necessarily) come with the same pain in onboarding, jumping between repos/projects, undocumented "oh sometimes you have to re-install that to get it going" works-on-my-machine bullshit, getting a good feedback loop going, et c.

[atmosx]

Where you able to see error logs from slack or you used a link? Granted that usually traces are multiline, I expect them to be hard to read on slack but the again nothing beats lack of context switch.

[awinder]

We linked out to the logs, I kinda wanted to figure something else out for slack to embed them but it ended up not working out. But you’re right it’s kinda appealing

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

[Ididntdothis]

I have found that just a few informal lines are often very good. What does the code do? How to build? Quick architecture overview. How do components work together? Good devs can usually quickly pick up from there.

[krishna0512]

Thanks a lot for your hard work!! It's because of people like you that I have a very good life.

[chrischattin]

I really appreciate people like you.

[DerekQ]

How are you storing and sharing these docs? Is it a common Sharepoint library or something similar? I've found the biggest problem is often getting people to look at the document resource / archive when they have a problem whose solution might already be documented.

[rorykoehler]

I wish I knew more people who think like you.

[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... (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

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

[sevengraff]

Interesting, got a blog that goes into more detail?

[bertr4nd]

We wrote this paper about it for CGO: https://research.fb.com/publications/optimizing-function-pla....

But the paper actually describes a significantly more sophisticated heuristic. My initial implementation simply used the number of perf samples divided by the size of the function, which helps make sure you’re getting the most out of your I-TLB. It worked shockingly well for its simplicity.

[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

[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

[itsArtur]

I don't think there was one specific thing that helped me keep these sessions going, it was a long a pretty long and tedious process, to be frank.

I had to convince both sides: 1. the management so that they would give us explicit permission to take time from our "actual work" time 2. the devs to actually start and keep it going

management caved in after... - I researched our competitors and their tech, highlighted features which would be very hard/impossible to implement given our architecture and what we needed to learn - dozens of comments about what we lose implementing feature Y in the "old" and "known" way vs using tech/service X - made comparisons to different professions which always have to stay on top of their game to win

all while repeating the message that we cannot have a world-class product without a world-class tech team. I think framing this as a "loss" instead of "gain" helped a ton.

With management buy-in, we were creating a "learning" card for everyone in the tech team each sprint. These cards were "committed" so there was no getting around of finishing them.

The dev team needed some motivation as well. Coding features as quickly as possible has obvious and visible advantage - you get praised, you might get a bonus, you might be promoted. Learning on the other hand.. less so.

To keep a long story short, I convinced them that the more they know the better their market value is by showing various stats. After the initial nudge, it was just intellectual curiosity that kept the meetings going.

Format wasn't anything special: - pick a book/article/system by vote - one person spends a couple of hours going through the chosen 'thing' - prepares a list of items to talk about - people vote about what should we talk about (before the meeting) - we have a presentation/discussion. each meeting ends with - list of practises/ideas we would like to implement. the list is committed to our documentation repository and followed up on - list of things we would like to learn in the future

[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!

[maddynator]

Mind sharing few tech books, blogs etc that you used for this review sessions

[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

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

[mythrwy]

Possibly you have a bright future in management :)

[mitefinedailes]

Heh, this is not the first time I get this feedback :)

Currently, I'm having more fun building software tools that are actually useful to people. Who knows, maybe a few years down the road I'll get bored by this, and dedicate my time to other activities ;)

[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).

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.

[james_s_tayler]

Our org was very much like this. Just couldn't get engineering specific tickets done at any meaningful velocity in such a product driven pipeline. It has finally changed with the introduction of an Architecture Practice Group where we do long term strategic planning across the engineering organization and a dedicated platform team who work on implementing the outputs of the practice group.

Finally feels like we're actually getting somewhere!

[wool_gather]

I'm just coming around to this position after a long period of frustration, and this anecdote is encouraging; thanks!

[celticmusic]

> The sad reality is that most orgs which run on a ticket/sprint process will make room for nothing outside of tickets.

I actively try to stay away from this for this reason. I understand that these ticketing systems are used for coordination and communication, but there's a downside to going all in on them.

[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

[mavelikara]

How big is your team?

[khalilravanna]

When we started we had maybe 4 engineers going. Now it's like 12 going to the meeting. It's a bit more unwieldy but still works.

What we've talked about is basically if it continues to grow we'll need to be a lot more structured or have to splinter off into groups with a good ratio of experienced to less-experienced engineers to still maintain learning.

[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. 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.)

[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...) 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.

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

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

[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/

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