Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What did you do to improve your company?
181 points by kalimatas 10 months ago | hide | past | favorite | 168 comments
Hi! I work at a mid-sized tech company as a Software Engineer. There are, probably, tons of things we can improve in our processes, infrastructure, technologies, etc. But sometimes it's hard to see the place with most impact from within, especially if you are pretty long in the company. That's why I'm looking for some inspiration.

So, how did you improve your company? By that I mean: processes, tech stack, optimization, etc.

I left.

The people were decent and the product fine, but my personal interest in the company went from "eh, sounds kind of interesting" to "why am I here...?" very quickly, and every day felt like an uphill battle to not rub my disinterest off on my coworkers.

Looking for inspiration is a mind trap that is best avoided. Inspiration comes when you are silent and you listen to yourself (and those around you). Keep an open mind. What you feel inspired to do may take you in a very different direction than you expect. Maybe the company doesn't need a new tech stack optimization, but would benefit greatly from a BBQ in the park - also no better time to get to know the people you work with better than when they are not sitting at a desk.

If you want to improve your company, listen. That's all there is to it. Listen to the needs of the people you work along side and then answer those needs. You are a part of a small tribe and that tribe values and benefits from active listeners and naturally inspired contributors.

Forceful inspiration typically has an opposite effect, so be mindful of your underlying drive.

I also left. Productivity shot up and office supplies theft plummeted.

> I left.

You know, this is one thing I need to learn: when to bail out on a situation that's beyond repair. I have a bit of a mental block about quitting without anything lined up, and job searching is just annoying enough for me to not want to do it without the incentive of needing to replace a paycheck. But, there are definitely a couple times in my career that I should have left long before I did, and I believe things would have worked out much better for me if I had.

I'm interested on anyone's thoughts on "when it's time to leave."

It's a good question and probably depends more on your personal circumstances than the job. I have often felt like leaving when I didn't agree with some core aspect of my org (product, culture) but I try to be pragmatic and accept that I am paid to be there and although globally I want to do something more fulfilling, it is better to lo cally tough it out and wait until I'm well positioned to make the next move. So maybe one thought is to ask yourself what is missing for you to be able to make a move, and try and work on that.

Incidentally, at my last job, I realized that what I was lacking to land the next job I wanted was also what I was lacking to be successful in my then current job. In the end I made progress towards remedying that, moved to a new job but also left on a high note as a result of my personal improvement.

It depends on what you value and what your drives are. But to give you a bit more tangible advice. When you are asking your self "Is it time to leave?" a couple of days in a row, it's probably time to leave. And don't fear leaving, the amount of growth and experience it brings you is mostly already worth it.

What Dev resources (blogs/books/etc) could you recommend that could help better explain this mode of thinking and how to turn it into a practical and practicable methodology of working?

I'll suggest Goleman's Emotional Intelligence (for empathy) and Pirsig's Art of Motorcycle Maintenance (for quality and values).

Massive upvote for Pirsig. I did not understand Apple until reading this book. I think Tesla maybe our contemporary equivalent.

Can you please explain in a paragraph what this book made you understand about Apple?

Granted it's been about 10 years since I read it...

In addition to what electrondood said. It helped me understand that there are some people who just want their technology to work. Not to understand it's qualities. John Sutherland (the character with the BMW). Many Apple users are like that. They want the defaults to work for them. They want to remain clueless and it "just works" ...

And I think getting to the end of the book, and seeing Pirsig descend into a pretty dark place in understanding quality being undefinable in any actionable way, I guess sometimes it's easier to just let go, and not understand something. A lot of times, understanding just makes us more miserable. Fantastic book, read it as a teenager and it deeply affected me.

A gross paraphrase I got was "I cant define quality, but I know it when I see it".

That's a great one! Something that can be validated yet not easily calculated. Kind of like hashing!

It's basically an exploration of the elusive quality of Quality, which Apple is obsessive about.

My general advice for anyone who has a little spare time at work and is looking for how to improve their company but doesn't know where to start is:

Take out the garbage.

By which I mean, everybody has a part of their job that they just don't like to do. It's a necessary chore, but not fun or interesting or exciting in any way. Look around you for that kind of work that's already being done by your management or your peers. Take that task off of their plate (most folks will gladly give it to you) and do it for a while, and then see if there's a way to eliminate it, automate it, or otherwise improve the experience of doing the job.

Especially as a software person, the amount of power you have to take little parts of the business that are rough and make them smooth is tremendous. Taking out the garbage is just an easy way to get started helping out.

I'll say this also applies to your first few weeks/months in a new codebase. Find the little problems that everyone else is ignoring because they have bigger things to worry about and tackle those for them. Beyond being helpful to the team, it helps you learn the territory of the codebase more quickly than you otherwise would.

As a cautionary tale -- make sure that there is fundamental institutional support for the removal of said garbage. If cleaning up the garbage requires help from someone else within the institution, verify that they can and will help you before you begin.

Source: I volunteered to remove some challenging/delicate garbage without sufficient institutional support. The lost productivity has had a marked impact on both my career and our team's success.

I'll second this with a personal anecdote as well.

If you do want to do this, clear it explicitly with your manager/person doing your perf reviews...

I had a non-technical manager who thought I was "avoiding" work by doing this instead of shipping new features and received a negative review because of it, even after explaining the situation.

> who thought I was "avoiding" work by doing this instead of shipping new features

Haha same. Mine thought these were unfinished tasks from my previous work and only have to do it now because i was slacking before.

this is true, I've seen someone here lamenting about how people changed his callback code to async while he was adding new functionality which resulted in him changing jobs.

> Take out the garbage.

I don't agree. You don't get promotions/pay hikes/bonuses for taking garbage out. Those are given to ppl who ship products directly bringing in tthe revenue.

> I'll say this also applies to your first few weeks/months in a new codebase.

I agree with this.

I'm on a project right now that's essentially all "taking out the garbage." I sort of feel like a garden gnome, fixing minor little issues here and there, but, this is all being done with institutional support, from my manager on up, so I have no doubt that I'll be rewarded appropriately for it. One of the bigger components of the project is going to end up saving one of our client teams about 9 man hours a day. In the end, I think that's a good enough result to justify a little garbage hauling.

> this is all being done with institutional support, from my manager on up,

I would be very careful with this. I made many mistakes like this. Unless you know this personally, I wouldn't trust this if its coming only from your manager and one level up.

People who control purse strings just don't care about garbage collection.

Even CEO should understand and value the project you are working on.

I don't think there's a disagreement here: notdonspaulding's advice was for "anyone who has a little spare time at work and is looking for how to improve their company", not for "anyone who mostly cares about promotions/pay hikes/bonuses".

> You don't get promotions/pay hikes/bonuses for taking garbage out. Those are given to ppl who ship products directly bringing in tthe revenue.

I'd disagree. Pay hikes and bonuses, maybe. But promotions are likely to go to someone who is stable and reliable. Why would you promote the fastest coder out of a coding job? Tech leads and managers are often the ones most comfortable in the system and the one who doesn't yell at others when he's interrupted.

The other little thing a lot of people forget is that it's hard to get anything done in a room full of garbage. So this often leads to better things for the team.

I think one of the marks of a good manager is they look at who is doing the quiet background work and make sure they get credit for that organizationally.

I am not saying all managers do that, or even that I am good at doing this, but this seems like a core responsibility of managing a team

There's a difference between taking out a little extra garbage and being taking advantage of. I think the OP is referring to doing something like removing an npm warning message in a build or adding a few sentences to the documentation on a Friday at 4:30pm instead of leaving early.

> You don't get promotions/pay hikes/bonuses for taking garbage out

Cleaning and streamlining processes and procedures can have huge effects on the company and get you noticed.

It starts with little things, Say you decrease compilation time by 30sec which could add up to hours a week. Or clean up documentation, making on boarding new devs easier.

Then one day you clean up something that has a huge impact on the company. Like a 40% reduction on server costs, by dynamic scaling... Then you're likely to get a promotion...

That's a good advice, it's the little things that usually get noticed. I was the one who kept the coffee maker clean, every week I'd wash all the parts and make sure we'd all get nice coffee. After a few weeks it started to catch on and other people also started to do it.

Little different swing on things, but I'm an industrial engineer focused on improving factory performance. And a lot of that is simply building and refreshing reports. Often Excel, sometimes Access SQL, and occasionally R scripts. It's not particularly glamorous, but it truly does drive business decisions which neat to see.

Every time I start a new role, I write up detailed standard work for the processes and make notes of what can be improved. As time allows, I make those improvements. I also keep rough track of how long each update takes, so if I have 20 minutes before a meeting I can start and finish a task. This helps me on performance reviews because I can objectively say "I removed 1 FTE worth of report updating, creating ongoing cost savings".

The productivity gains are amazing. Over time, reports become fully automated. Logging improves, helping trace down errors. What used to be 8 hours per week of report updating becomes 20 minutes of validating data.

It's 10x easier to take a week off if your tasks are documented. I routinely write up a process then make another team member do it, so I can find the weakesses and fix them. This helps the bus number, and makes it easy for someone to cover for me if needed.

Prior to my joining the team, our homemade migration tool used sequential versioning numbers for filenames, i.e. 001_migration_name.sql, 002_migration_name.sql.

As our team was grew, it was very common to publish a PR, and right before merging realizing you had a conflict with someone else who'd merged to master ahead of you, using your sequence number.

I made a small change to the system, replacing the sequence numbers with unix timestamps and added some previously non-existant tests to cover the migration utility.

Unfortunately the subsequent PR took weeks to be approved by the team/eng leads because there was a lot of hand-wringing about this change. Once it was merged though we never thought about it again, it worked exactly as I'd hoped and nobody ever had to make a final "fix migration name" commit again.

I used to lose so much time to that, imagine coupling it with multi week code reviews (another process that needed to be fixed). I'm actually building a migration tool as part of a web framework (free time project). I'm going to "steal" this idea of yours if you don't mind.

To play devil's advocate, probably part of the reason for the sequence number approach is so if that PR that merged ahead of you conflicts with your migration you're more likely to notice if you have to rename it. I don't think that's particularly common though, and the problem should surface when the CI build runs your migrations prior to permitting the merge to master ( a good CI setup requires you to pull master into your PR if it's out of date, which ensures the combination didn't break things.)

Funny my team had the same issue and I did something similar, except I went with one file per release and they would merge changes like any other code file.

Listened to people.

The organization I worked at had no direction. Low morale. Lots of complaining. No leadership from people in management positions.

A colleague and myself tried some of the things mentioned by others below to build camaraderie, etc. Minimally effective.

Then, we started talking to colleagues.

"What's going well?" "What challenges are you facing?"

Listening alone, letting these people know their voices were heard by anyone, went a long way in building relationships, alignment, and getting things done.

Then we took what we were hearing, developed an initiative, pitched it to leadership. They rubber stamped it without really paying attention or asking questions.

We executed.

People were shocked. Their voices had been heard, and something had been done to address common concerns they had. I don't know how to measure or describe this impact, but it's the most significant thing I have ever accomplished.

What was the after story, if you don't mind going further? This is super interesting, I'm curious what happened with you/the company afterwards or on a longer horizon

Sure. This was a school/school district. We thought big, and started small. Our initial initiative was for K-6 only. In the following years, this spread to both the middle school, and then the high school. Driven by demand from the teachers themselves.

The modern era of education reform goes back to the Soviets launching Sputnik, so 60 years. It has been omnipresent reform efforts in K-12 education since then. Lots of change, little improvement.

We created not only a durable change, but a positive one that is still pointed in the same direction five years after we got this off the ground.

There's more detail about what we did in a reply below you.

What was the initiative you had? The common concern that you fixed?

This was a school/school district.

The common concern was lack of direction and changing direction with new change initiative one/two/three/four times per year.

We created an initiative for teacher created and led professional development. We used students for live class recreations where teachers could analyze in real time. It was coordinated, structured, and sequenced in a way no teacher's in our district had experienced.

At the same time we took all of the feedback we got from every teacher we interviewed (and we interviewed all of them) and created a vision statement for both teachers and students. We took it back to the teachers and showed how each person's feedback was reflected in the vision. We got the district to adopt the vision. Then we held leadership's feet to the fire and didn't let them do anything that didn't align with the vision. We put the onus on them to explain how any decisions did align.

We used the vision to design professional development, adopt curriculum, craft special education services, and more.

This started as a K-6 initiative, which was wildly ambitious at the time. In the following years the middle school got on board, and then the high school followed suit, led not by administrators but by the teachers themselves. Something we never in our wildest dreams thought would happen.

Five years on the direction is the same and positive change continues.

My experience is that you can often find low hanging fruit, relatively easy changes that will have high impact. For example, I've created checklists for some of the processes that we do often, especially when it involves coordinating with a customer. Creating the initial version maybe required a few hours, but since then has been used 100's of times to shave 1-2 weeks off of work and reduce errors/surprises.

Another example is really basic automation. You probably have people/teams around you that are not developers. They probably are spending time doing really basic repetitive tasks. One team I work with regularly would take a spreadsheet, then for each row create a folder and docs in Google Drive. I wrote them a Google Apps script that could do the task with a click. Not quite as impactful as the checklists, but each script like that saves someone a couple days a year.

I read about a really cool way to move to having stuff automated - on here I think. You make a bash script as an interactive checklist (e.g. step 1 flip the floop then press Y to continue) and then you can automate steps one by one as time permits. You can also have a log of the steps being done then as well.

The primary benefit of automating small/ (mundane?) things is that it gets rid of a some of the cognitive load.

For example, I wrote some shell scripts, gradle/TC plugins, when my company moved to kubernetes/openshift. We did not have devops, paas standardization then. The scripts are now getting used in many projects in a couple of departments. And it was just word of mouth adaption. It is as not very fancy stuff nor is it a company wide standard. But it is useful and it hides/gets rid of complexity which new projects/developers no longer have to worry about. Danger area: trying to be too generic, parameterize everything, you end up with frameworks and processes. As a senior dev, I generally aim at solving my problem and if possible making the solution usable in the immediate vicinity. Keeping it minimal and simple makes it usable for others when the problem is not exact match.

I've done this!!! It works _great_! I have a setup script that new employees run and I never quite figured out how to automate one of the steps, so it just prints "Go to www.example.com/whatever and paste in the API key it generates below." It's been 1.5 years and it's still chuggin' along just fine.

I did the same thing for a consulting company. The onboarding process involved creating and populating a google drive folder, a slack channel, and a trello board. I used Zapier to create everything off of one entry in a google spreadsheet.

Tons of fun for me, saves some time for someone else, created consistency for everyone.

Your last example is also the sort of thing that makes people really happy.

(And, unfortunately, a small number of folks will practically hate you for it, since you're taking away their "easy" work.)

I'm a Dev Manager but started as a mid-senior developer at my current company (now about 350 people). We grew a lot by acquisition and one thing I noticed was many "cultural silos" that made it hard to build a shared, unifying identity. Myself and another developer worked to try and address this with a lot of small things focused on cutting across teams & groups: a book club-style bi-weekly discussion, "Tech Talks" from across the teams to diverse audiences, some hackathons and making online conferences (MS, AWS, Google, Etc) into company events. Literally things that "make people spend time with people outside their direct team". It's been pretty successful and pushed lots of new initiatives in some unexpected areas.

So my advice would be to look for a broader area where you see a gap or failing, and then look for ways to address this that don't need a huge investment of people or resources; guerilla activities FTW! If you can show some success, you can then pursue as appropriate/desired...

I tried that - called it Tech Shorts (lightning talks) at small company. Found the largest issue was Passiveness in the engineering crowd. Ended up giving about 50% of the talks myself, not because I wanted to, but because there were so few people who were willing to step up and present. About 70% of the engineering team would attend (~50 people), so it was well received. Will try a new iteration next time.

What made your attempt successful, in your opinion.

I don't get paid to give tech presentations. Preparing for them would affect the work that I am responsible for. So giving tech presentations would ultimately make me look worse at my company. This explains the passiveness at my company.

This is my observation across several companies/teams. The options seem to be either sacrifice "real work" time to make a good presentation or make a half-ass presentation and have people criticize the low quality.

Do people here think "no prep" presentations could work? Where it's agreed that nobody will do any prep but simply talk about something they're knowledgeable about? Or share their screen and walk through their current project? Everyone in the audience knows that the presenter wasn't "allowed" to prepare so the expectations are lower, but people still get exposed to other engineers' work.

In medium-large companies, work and promotion are about showing off. Even if you do real work it's more important to be noticed than to do it.

In that light, I don't understand how you and the OP could consider that it's preventing to do real work. Powerpoint is the real work. And it shouldn't be difficult to justify spending 1-2 days on it, with 100 people assisting to the presentation as witnesses, unless your manager really doesn't want you to give presentations (it's showing off your team so it's good for your manager too).

I get it that it's not part of the engineer mindset of course. If I have to give some advice to strong engineers who do good work, that would be to take credit for your work.

That captures a lot of what I was trying to capture. However, the intent was for people to cover work that they are doing (lowering prep time, immediate understanding), tech they are researching (again lower prep time, immediate understanding).

A lot of technical presentations we did are no different than what you would do explaining tech within your team. A few diagrams, and understanding of the core of the tech. Scaling to more than the safety of the team is really where I think people would rather have 3 meetings with 3 different teams to do a knowledge transfer than take the risk of being in front of collecting 5-10 teams worth of engineers.

Looking over the comments, the real gap I expect is the lack of peer management support and encouragement. And expectation that mentoring and teaching peers should be part of the leadership expectations. My view are is the the strongest engineers are the ones that accelerate and multiple the work of themselves and their peers, but there are a lot people who subscribe to the "army of one" 10x engineer philosophy.

It is a part of the "engineer mindset"

This was exactly what it was.

Demo, deep dive/narrative on your work. Demonstrating something cool. It was clear the prep was not expected or needed, and it would be scrappy - just like lightning talks at conferences.

The exposure and sharing of ideas was critical.

We even had times where someone would suggest a topic during the meeting and someone would step up and do a deeper dive into it.

Understanding is all relative. You don't need to be an expert to know more than your peers. You just need to accept that your extra knowledge adds value. And be honest where your limits of understanding are.

That's where you need buy-in from management. One of my past employers had a presentation series like that above, and if you were scheduled next, it _was_ considered work that you were responsible for, and counted towards more or less a half-day.

I haven't been at my current employer long, but from what I've heard about our frequent engineering meetings and their presentations, they do the same thing.

At my team we "ticket" presentation prep just like dev work. So if you wanna do some sort of story point / ticket anlalysis per dev is no different.

Make it 5% of the work time. Make it part of the job (I also doubt you're working 8hrs at full productivity mode)

That attitude is asking to get a "needs improvement" on your APR.

We have something similar at my current place where every week or two someone presents.

It ends up being the same people presenting and I don’t think it is because people are afraid of public speaking, but instead people don’t care about the talks.

At most 1-2 people (~20 person eng team) will ask a question, engage with the speaker, say thanks, etc. but most people either don’t attend the video call, or do so with video and microphone off for the entire time.

I long for a group of engineers who care about honing their tools, finding better solutions, making things reliable and efficient, etc.

It becomes draining to have the same people present over and over again.

/end rant

> but instead people don’t care about the talks.

Are you taking into account this kind of comment by Dan Luu[1]:

"Most people consider doing 30 practice runs for a talk to be absurd, a totally obsessive amount of practice, but I think Gary Bernhardt has it right when he says that, if you're giving a 30-minute talk to a 300 person audience, that's 150 person-hours watching your talk, so it's not obviously unreasonable to spend 15 hours practicing (and 30 practice runs will probably be less than 15 hours since you can cut a number of the runs short and/or repeatedly practice problem sections). One thing to note that this level of practice, considered obessive when giving a talk, still pales in comparison to the amount of time a middling table tennis club player will spend practicing."

From that, you might ask your presenters to do 2-4 hours of rehearsal, and for the talk to generate $2,000 of value before it's worth running / worth attending.

I feel many talks are "what the presenter wants to talk about" not "what the audience wants to hear". At least at a tech conference or on YouTube you can self-select so those two overlap. Inside a company, less so, so it's more important that they are done well, actionable, preferably short. They can't solely be mandatory. or solely fun for the presenter. And they certainly can't be spinning a tale of a utopian future for the company which is worse for me personally, or teasing me with a future tool or process or change which is better for me personally but which the company won't permit or won't get behind or actively opposes.

[1] https://danluu.com/p95-skill/

When talks are given through video I actually attend a lot more than when they are in person. I put them on, turn off my music, and listen while working. I've actually learned a lot of stuff this way. Of course I'm not putting 100% effort into work, but that's fine. And if it is a talk I'm not interested in that percentage of focus on work is much higher.

Just because people are lurking doesn't mean they don't find value in your talks.

> Passiveness

A lot more people have some degree of social anxiety than one might think, especially in IT.

Lightning talks originate—and work well in—the sort of tech-bro workplaces where there’s an Xbox, foosball table, and bar in the breakroom. Half the “culture fit” criterion of hiring for those places is just an attempt to filter out potential hires with any amount of social anxiety; so the average level of it in such places is low.

But other than in that little ecological niche, you’re not likely to see many engineers who are fond of public speaking, even when they have something they know and would love everyone else to learn about.

On the other hand, though, many of these same more anxious people are fond of writing. Unlike public speaking, which is a live performance, a written piece can be composed—worked out slowly, checked for errors, re-drafted, thrown out with no repercussions, etc.

Many engineers who aren’t at-all interested in giving a lightning talk, might instead quite like to blog about what they’re doing in some official capacity. And they would like it even more, I expect, if they didn’t have to have final responsibility for what was presented (because there’s always still the anxiety that someone might spot a flaw in your argument that you didn’t); but rather if their prose was handed off to a managing editor for the blog, to work up into a final article.

Which means that a lot of these same engineers would be fine composing a lightning talk, as long as they didn’t have to be the presenter, and also weren’t put on the spot to answer questions afterward†. Find someone in your org who just loves talking—maybe a salesperson, maybe your CEO!—and have the engineer in question work with them to transfer the knowledge necessary to give the presentation. As a bonus, the presenter gets to be educated in this stuff from the source, one-on-one; which can very much help improve the depth of their knowledge, when that same person is communicating with your customers!

† Q&A is a very valuable part of a talk, and the knowledge required to answer arbitrary questions really has to come from the engineer themselves, rather than a presenter. I’d suggest still doing Q&A with the engineer, but asynchronously, so you’re not putting the engineer in question “on the spot” in front of an audience. Maybe set up a mailing list or group-chat channel, that everyone attending the talks can subscribe to, to ask questions relevant to the latest talk. Then there’s no time-pressure on the engineer’s part to respond, but everyone still gets to ask questions, and to hear the answers to others’ questions.

> A lot more people have some degree of social anxiety than one might think, especially in IT.

I was interning at this place and the team lead would come and ask the interns what they were doing (at least once a week) and ask really in depth questions. It was extremely nerve wracking because this was the only interaction I had with him and he kept a air of "hard ass" around him. Every few weekly meetings he'd ask the interns for more information and put us on the spot.

It sucked. BUT by the end of the internship I think we all felt a lot more confident speaking and defending our work. So I guess his plan worked, and honestly I'm happy to have had that experience. I think it made me not only a better worker, but a better employee. At the end of the day, we all are in sales in some form. So I do not like the idea of someone else giving the talk, because that's not the person that gets the training from it.

What I'm trying to say is that talks like these really should be used to help your team members with anxiety. A bit of low risk exposure therapy. Speaking is a skill and it is an extremely useful one to every person at every stage in their career. You are supposed to train your employees and sometimes that means making them a little uncomfortable.

As someone who's decently comfortable with public speaking:

Your employer is not your therapist and conflating the two is one of the most terrifying things I have ever read on HN.

Calling this "conflating your therapist and employer" is an unfair accusation and clear reductio ad absurdum.

It is training. You are expected to train junior engineers, not just in tech but also in soft skills. Public speaking is a soft skill. It is also something they do in schools. You have to do classroom presentations and reports. I don't think you would make the same argument for them.

Your job should be making you a better employee than you were when you came in (and not just in your hard skills). This is especially true for junior positions. You will be expected to defend your work to your boss and employers. No one is saying to give a talk to an open audience. But you should be able to clearly justify your work.

> talks like these really should be used to help your team members with anxiety. A bit of low risk exposure therapy.

> You are supposed to train your employees and sometimes that means making them a little uncomfortable.

Reductio ad absurdum only applies if the source does not already convey that message. This literally says that your employer should be providing therapy for anxiety. (Not providing a therapist, literally performing therapy) There's no ambiguity there. It's in the original text, right there.

Anxiety and soft skills are related but soft skills are a thing to learn and be taught and anxiety is a condition. If anxiety is in the way of learning soft skills the solution is not for the employer to provide therapy.

That is not what was intended. I know because I wrote it. It was a push to the most absurd interpretation.

As for anxiety, you should talk to people with it. It is a spectrum. Being nervous and anxious is not a medical condition but the human condition. Being unable to breath and having heart issues (i.e. a panic attack) is a medical condition. There's a clear spectrum here and and equating nervousness to an anxiety disorder is trivializing the condition that people actually suffer. Clearly I'm not saying you should be forced to do this if you have a real condition (ad absurdum). But if you're just uncomfortable and nervous, welcome to the human condition. While you enjoy your stay I would appreciate it if you don't trivialize medical issues. If you do have medical issues: please seek professional help, and I'm sorry if you interpreted my message as inclusive of you.

+1 here.

An individual's team/employeer/peers/manager should create the space for your to lead people (which in a lot of cases means stepping out in front of a lot of people), and to be supportive relative to the experience.

Individuals need to take responsibility for their personal growth and find avenues (twitch, toastmasters, meetups, etc) to get stronger that doesn't rely on your employer.

Another option is pre-recording your presentations. Shoot for a 15 minute presentation, followed by questions and conversation. Think a dev recording their screen, showing the work and talking over what they're doing, mixed with a few powerpoint slides.

This gets over the hump of public speaking, creates an artifact that can be sent out as a follow up, and gets to the goal of having shared knowledge of a topic and a sense of community outside of normal silos.

> because there’s always still the anxiety that someone might spot a flaw in your argument that you didn’t

What's the need to always being 100% right. There are very few situations where there is a 100% right solution. Most are optimized 80-90% for a particular problem set. Indicating that "within our context, we believe this is the best solution" goes a long way in creating that opportunity for discussion and deeper understand of either gaps in the context for the problem, or adjacent problems that may leverage the work.

Wanting your blog to go through an editor isn't about needing to be right; it's a "defence against the dark arts" of paparazzi quoting your words out-of-context with the intent of getting you pilloried by the Internet.

I think that's a pretty myopic view... Personally, I think taking more chances to positively affect your workplace "technopolitical ecosystem" ultimately improves your ability to do your job.

This doesn't surprise me at all. The intersection of engineers and public speakers is pretty tiny. It's not recreational; it's high pressure. You need to find something fun and laidback. Something low stakes, like a semi-weekly video game competition.

It's not high pressure, really it isn't. It's the same as when you talk in a team meeting, just more one-sided.

The pressure that people feel is mostly self imposed. Most of the time the audience is there to learn given they have a gap. Most people are projecting their fear onto the presenter. Unless you are an actual leader of an organization, you are just one of the team.

(I'm a reformed strong introvert)

I'm not sure if your comment is directed at me or used for rhetorical effect. Either way it's confusing and a little bit offensive.

The first thing is that there's a signal here that you believe there's something defective about introversion (i.e. that introversion is something to be reformed). To those who don't know, it's just a neutral personality trait (one of the Big Five--low extraversion) with its own pros and cons. There's nothing wrong with it and it can be happily embraced.

The second part is that you seem to have the common confusion of conflating introversion with poor public speaking (or at least an aversion to it). They're unrelated. Introversion just means interacting with people expends energy. The actual aversion to public speaking comes from lack of skill, anxiety, and awkwardness. I grant you that those things might be more prevalent in introverted people because it is easier to keep to yourself and not build those skills, but they're still two different things.

Finally, saying it isn't high pressure comes across as somewhat lacking in empathy. People feel different ways about different things, and invalidating those experiences is not helpful.

Personally, I have improved my public speaking a lot over the years by forcing myself to do talks, toastmasters, host meetups, etc. Now I'm pretty good at it and comfortable with it, but there was a ton of pressure and anxiety around it before. Even though it's better now, that doesn't make those experiences less real for myself or anyone else.

I'm interested in anyone's experience doing this with a remote team. We do this (in a small but distributed team), and it's as much about keeping shared technical knowledge up-to-date as getting together.

But it can easily turn into just-another-zoom-call. Ideas?

We did week long hackathons across the company and anyone could join any team. In fact people were encouraged to switch roles and teams for the hackathons. Especially QE becoming devs or devs handling BA type roles.

That sounds great! Have done similar things and recommend.

I implement a few changes wherever I work:

- Commit messages must include a ticket number (or a keyword like "hotfix"). This is enforced by a commit hook that's bundled with the project.

- Ticket templates that encourage clear tickets. A ticket should always explain why it must be done. It should also contain enough information for any team member to judge its priority, or start work on it.

- Any relevant discussion about a ticket should be in the ticket.

Just enforcing this makes a world of difference. It ties every bit of code to a justification. This way, if you decide to rewrite the project, you won't end up losing years of discussions and important lessons. You'll also have a much easier time prioritising and assigning tasks, since everyone knows what they mean.

Aside from that:

- My first pull request at a company is usually an update to the README file. It rarely matches how you actually use the project.

- I write "recipes" for common tasks (lint, deploy, test...). This way, you know that the CI system and every developer in the team performs those tasks in the same way. You can change the recipes, but they are always called with the same command. "scripts/clear-cache" is also easier to memorise than "docker-compose exec backend rm -rf /var/cache...".

- Add :party_parrot: to Slack

Are you me?! Even the party parrot emoji.

Maybe? Do you get a weird feeling in your right elbow when you apply cold water to it?

1. Simplify - as a rule of thumb, if something looks too complicated it probably is. If you think there are too much "ifs" in the code, there certainly are.

2. Remove any "shiny-new-toy". A perfect example would be my bank, which operates in ~15-20 countries: Their interface isn't a shiny web interface with pretty animations to cover up a slow response time. The interface all employees use is built with ncurses. That speaks volumes.

3. Profiling the code and by doing so find unnecessary bottlenecks.

4. Never blindly reinvent the wheel. If a solution looks absurd but is highly used, chances are the solution is there to cover an edge case. Ask before you decide to "fix" it.

i feel like there is an appropriate middle ground somewhere between "shiny-new-toy" and ncurses...

It's probably a 15+ year old application, which, if it was web-based, would be built on 2-3 out-of-date webstacks, badly joined together, with who knows how many security flaws.

Compared to maintaining that, ncurses doesn't sound too bad.


I used to provide dev teams with cli tools (testing, infrastructure debugging, etc.). They used them from time to time but only after implementing basic gui with tkinter or simple html/js/css they started to use them more often. I prefer terminal more than gui but if you don't use terminal 90% of the time it's much easier to click the button on a website.

You are right - that's ncursesw ;)

Hypothetically... Late 90's web, which wasn't bloated with 150mb javascript files which run your CPU at 10000000%...

I recently read this book and found it very interesting and useful. I think it might be for you.

The book is: High Output Management by Andrew Grove.

It is a dated book but many of the procedures described are still valid today (obviously using real digital tools).

I highly recommend you to read it. Improving a company often means improving the way people in the company work and interact while also increasing the quality of life of these people.

I think many of the practices described in this book are about these very things.

Good luck improving your business and sorry for my English (I'm Italian).

Thanks for the recommendation - and your English was perfect, I wouldn’t have known it was not your primary language.

Not me, but a "startup" I'm consulting for today that's pivoted many times over the last 13 years. They spun out a different website focused on a single offering about a year and a half ago that led to them developing a focus (sales and tech both) on a specific market and has led to a crazy uptick in business. I can share the URLs if the HN community is curious to see the difference between the two.

Editing to include URLs: - Original site: www.devhub.com - Spin-off: www.rallymind.com

Since you consult for them, what can you honestly say about the quality of rallymind.com. I'm working on a couple of projects that will need quick, simple payment.integrated landing pages and this service looks interesting. Any opinions of them?

Yes please.

I edited my comment to include the URLs. Interested in what you think, let me know when you have a chance to review.

Would love to see this!

Edited my comment to include the URLs. Let me know what you think and if you have any questions. I can try to pull some SMEs in to answer them if you'd like.

At one of my jobs, the very first thing I did when I arrived was redo the code deployment system to get the deploys from 30 minutes to 30 seconds.

Cutting deployment time makes a huge impact because it makes everything go faster. You can iterate faster, which means getting bugs fixed faster, getting data to product managers faster, etc.

It also has an effect on reliability. The faster you can make changes, the faster you can fix errors (as long as you aren't introducing them faster too!).

It's always the first thing I focus on.

> At one of my jobs, the very first thing I did when I arrived was redo the code deployment system to get the deploys from 30 minutes to 30 seconds.

We have the exact same issue in my company. Could you explain how you managed this?

The way I did it then probably wouldn't work now. I literally just wrote a perl script to automate pushing copies out to all the servers. They were doing all by hand before I got there.

If I had to do it today, I'd be looking at GitHub actions or some other similar CI/CD tool. If you're already using those, then I'd ask what is the slowest part of the process, and how can we speed it up?

To answer that question you obviously first need telemetry and monitoring to track each step of deployment. That telemetry will be useful in not only finding slow spots but tracking your improvement, which will help you both in operating as well as justifying your work to others.

I joined a small SaaS company when it was 15 years old, in the role of developer. I was the third developer on the team.

I dragged them, kicking and screaming, away from CVS into git for source control.

I did a LOT of documentation of their ancient and honorable :-) SQL schema.

I converted a lot of old legacy code to more modern languages.

I converted a lot of old legacy SQL embedded in their code to use prepared statements and stored procedures, and developed a tiny little framework to make it easy for other developers to do the same.

I came in early one summer morning and washed the windows in the office. Seriously. They hadn't been washed for 15 years, and were disgusting.

I helped talk them into replacing their low end home brew bug tracking system.

I pushed, hard, to get them to gradually discontinue using FreeBSD in favor of standardized Linux cloud distros.

I developed a way for sales, dev, and ops to communicate to do capacity planning BEFORE bringing on new gigantic enterprise customers, not after.

I failed to get them to adopt CI/CD.

I retired.

My working principle: always work myself out of any job. Do all my work so somebody else can take it over.

Document, host meetings, buy food, drinks and invite co-workers to have "time off" during a "work meeting" every now and then, but really documentation and generate good excuses that necessarily does not blame other departments.

Document pain points is a big one, everyone says them, but not always are they fixed or prioritized. Something to fix those will work - like creating, documentation, sigh.

People skills and politics, not even technical. :(

That's nothing to be sad about, quite the opposite. The longer you work in this field, the more you'll realize skills that make people "senior" are not technical most of the time.

I wrote a Copy/Paste stack tool. Pressing ctrl+c adds the current selection onto the stack and ctrl+v pastes off of the stack. You can toggle between LIFO and FIFO.

It's been very helpful for our client-facing folks who have to copy a lot of user data.

Windows 10 has that built in (search for "save multiple clipboard items" in the start menu), and third party ones have been available for at least 19 years (ArsClip - http://www.joejoesoft.com/vcms/97/ )

Surely they have also been available on mac and Linux for as long? Can it possibly have been a good investment to write your own?

I had no idea this existed, thank you for sharing. As far as an investment of time goes, I just saw this as a challenge and I enjoyed working on it.

I started using a copy paste with history (alfred on mac). Could never go back. It's such a massive workflow optimizer I can't believe the idea isn't more common. Function fixedness?

The is pretty cool and inherently useful. How do users see what's currently on the stack?

It's an inelegant solution, but the app uses a context icon in the taskbar and when you click on it a window appears that shows the stack in a table view. This is all being done using WinForms. I'm hoping to find a better implementation to be honest.

- Helped push for a shift in invoicing hourly to daily/weekly and then to "flat-rate for the whole team every month"

- Organized a professional development group to promote book clubs, meetups, etc within the company

- Helped marketing/sales folks update web pages to fix errors or "generic business language"

- Encourage and lead efforts to use off-the-shelf tools instead of homegrown internal tools

- Took meeting notes for all-hands meetings and published them internally

- Build relationships with non-technical staff so that you can later give them feedback about processes they control

These are some things I've done over 10 years at my company, so it's a long process!

I build visualizations and dashboards from time to time, mostly to scratch my own itch / answer questions, but sometimes people have found them to be useful.

For example there are dashboards to track the progress of certain tech debt we are resolving, like replacing icons (oh god that looks horrible on mobile [0]). On the process side of things, we have a lot of people reviewing code and I built this dashboard where you can see the availability of reviewers and how much reviews they have done in the past days. This might help distribute load and also allow reviewers to see when they are doing too much [1].

When we were hiring more last year, we actively looked into improving our hiring experience. That was a group effort, but Training other folks to do technical interviews was very insightful and contributed back to our process.

Tech stack wise there are a few skeletons in the closet. Generally once you start digging, you find a lot of weird things. We work together to define metrics in order to assert which improvements have the highest impact. Always important to go in the right direction, little steps, and verify that you are going in the right direction. For example we focused on decreasing our JavaScript that is loading on every page, until we realized CSS cruft was blocking Rendering more than the JavaScript. Then we switched focus to that. Now after we identified what to fix, we focus on the JS again.

[0]: https://leipert-projects.gitlab.io/is-gitlab-pretty-yet/icon...

[1]: https://leipert-projects.gitlab.io/maintainer-workload/

There are as many ways to improve your org as there are people working there :). Focus on what gives you energy, focuses your positivity and piggyback on it to create impact.

I love tech communities, and started internal and external meetup groups, found ways to stream online, managed to get the tech blog running. All things that I love doing : making other tech people more brilliant than I am successful.

Keep doing it, be consistent.

After a while, it will be seen, recognized and you will be followed :). The cool thing is that because it's something you like, it doesn't sound like work!

Good luck and let us know what you've found in a while !

I replaced our aging infra with AWS, oversaw replacement of a mishmash of C#, C++, PHP, and Java1.4 by a concise Java 11 based app, and I'm about to deploy our first PWA with a Postgres/Vert.x/OIDC backend. Legacy is still running Apache2/PHP5+MySQL.

I would describe the tech stack I've inherited charitably as "nearly pure opportunity."

Good on you for being able to focus on the opportunity.

Too many developers are discouraged when inheriting a legacy app. Nobody wants to be a turd polisher, but like you said, that just means there's even more opportunity for improvement.

What has your Vert.x experience been like?

I've been using it in production for 3 years and regret selecting it.

I raised productivity, morale, and the average skill level on my team by quitting my job.

Why do you think that was the case?

After reading Shape Up by Ryan Singer we decided to try it out. It's been incredible improvement. We are now able to focus deeply on hard problems, take guilt-free time to rest and sharpen our skills, and regularly think long term about the direction of our work. I just wrote about about it in-depth on my blog:


Encourage a culture of yes-ness and helpfulness. It’s so easy for people to say why something cannot or should not be done.

It’s so much healthier to say “yes, I trust that you need what you say you need but I need more information to be able to help you.”

I have done two big devops transformations so far in two different companies.. from manual deployments and no CI to CI/CD + infrastructure as code.

For me it usually goes with:

1. Have people trust you by usually executing a big project. For me it went by executing very well small projects and getting bigger projects until you're implementing a very big and critical project with a team.

2. Once you have executed (1) people usually trust or know you. Then you can start talking with people across the entire organization asking what hurts the most, make some list of things that are interesting to tackle and who would be the stakeholders

3. Choose one from the list of (2) and do it (or try to sell the need for it)! More often than not it involves a lot of conversation, empathy, teaching.. for example, if you want to implement CI/CD then be ready to:

a. Sell the value of tests

b. Teach best practices for testing

c. Have a skeleton project that people can easily copy

d. Have some tools to easily set up a Ci/CD for a project following the structure of (c)

e. Adjust notifications and workflows

And.. you have Ci/CD for a group. Now do the same for all other groups. Now your company has CI/CD, yey! Pick another item from (2)

I advocated at my own risk to try and improve our working conditions. Being honest and carrying out my work in the way I was most comfortable doing, directly and assertively asking for better physical and social conditions to perform our duties, and using my own equipment where theirs was a hindrance. The tech stack was relatively ancient, but I accepted that as part of the role, because it wouldn't have improved much of anything to swap YUI for another. Anyway, I learned after I was fired that our group cubes were replaced by something less soul crushing and more configurable, the sales guy who screamed on his bluetooth headset every hour while typing on his mechanical keyboard was moved, and the guy in charge of the failed project I was assigned to was promoted. So honestly idgaf about improving whatever company I'm at anymore. I just try and pick one that will not suck so bad and plan to stick around for 6 months.

I've created scripts to automate some repetitive or complex tasks. I've done this for two teams. I think it was an improvement since it eliminated human errors and freed up developer time. Some of the other developers appreciated it, but most people didn't really care.

I also came up with an architectural improvement not used anywhere else in the company that allowed us to close a security vulnerability related to a file copy process. I think the tech lead and the manager who owned the vulnerability were happy. Nobody else cared.

I think these types of improvements are fairly common and add up to great things, especially when multiple people have this mindset. Unfortunately in my experience most people don't have that mindset because it's not part of the culture where I work. Don't hold your breath for recognition or appreciation. The only way to achieve that is by improving something for the 'business people'.

Helped build, grow, and maintain a hackathon. Over the course of 8 years, we've held 21 hackathons. Some have been more successful than others. One of the things I've always done is protect the underlying goal: that it's 2-days the company gives for people to work on whatever they want. People have used this time to make furniture, work on games, learn new technology, and of course, work on new products or tools for the company. You do NOT have to present.

While not all hackathons have produce production level ideas, many have. One hackathon resulted in the initial iteration of the biggest product shift in our company. One that I'm incredibly proud of.

This might not be what you were asking for, but I know for a fact that doing this literally had the most impact on the company.

I decreased required HDDs size by 20% in CI system by adding "-ntp" switch to all maven commands. It makes the maven stop printing "Downloading..." when it downloads artifacts. How I did it? I added alias mvn=mvn -ntp in .bashrc.

Saved about $100k / year by switching to our own video transcoder service rather than outsourcing it to SaaS.

how many dev hours did it take to build it and how many dev hours / year does it currently take to maintain/update it?

One person, maybe two weeks to build it. Not sure yet on maintenance. But certainly not $100k.

I left.

So did it actually improve? Or did it continue to go down hill?

That's a large oof.

From 2003-2005: Co-created our database release process, integrated it with our code release process, developed our production problem management process, and built a bunch of our production monitoring tools.

Many of those things have since been superseded in the intervening 15 years, but it still pleases me to walk by the NOC and see tools of mine that I wrote 10-15 years ago still running (now maintained by others, but still running).

One of the most useful and longest-lived tools is one of the simplest (I literally built the essence of it in 4 hours, 6-10 PM one evening). It graphs a timeline, 1 second per pixel in X, logarithmic dollar value in Y, plot every order. That was the first version.

It's since evolved to have a bunch of per-minute summary data on the screen (AOV, CR%, errors/info/warning/404s, total bookings, paid vs unpaid orders, database connections in use, idle connections available, long-running transactions, long-running pages, etc per minute), records to a database, so you can "playback" outages or go exploring, etc. It's not the best tool for deep digging, but when you want a fast-reacting, "quick check" that the entire site is working post-release or post-outage, it's unambiguous that people are getting all the way through checkout (or not). You might be surprised what you can learn from such a simplistic tool.

We simplified our offering.

From the beginning, rsync.net offered standard ftp service along with ssh tools. It pleased me to offer an old fashioned standard that "just worked" and allowed some weird corner cases to function for people.

Simultaneously, I wanted a "clean" nmap. I wanted to see port 22 and nothing else. So, we disabled ftp (and with it, inetd on all of our FreeBSD storage arrays) and reduced our attack surface as well as the number of processes we need to run and audit.

We made this change about 18 months ago...

There are a couple ways to approach this problem. One of them is to examine the outcomes that are crucial to the business and recursively working backwards to the components that drive that outcome for the business. Once you get to the root inputs, you will be able to identify which changes will create the greatest increase in your desired outcome.

For example, let's say your company is a SaaS business that is number 4 or 5 in its market and is looking to move up to number 1 or 2 position, then you may find that the key strategy to get there (just spitballing here) is to get to feature parity with the market leaders. If so, then you would need to launch more features faster.

How do you launch features faster? Well, could be improving the code quality so there is less rework, building better tools, hiring more devs, etc? So lets take one of those, eg improving code quality. How do you improve code quality? Well, maybe hire better devs, train the devs you have or improve your QA processes? If your devs are all rockstars, then it must be QA that sucks. So let's look into how to improve QA.... (etc)

Keeping working down this logical path and you will arrive at the most impactful changes you can make in your organization.

I am lucky in that fact that I am a position where my opinions are listened to and respected. I have spent the last few years trying to improve a number of our processes. If I wasn't in this position, then chances are I would have moved on to greener pastures almost immediately.

Source control discipline is probably the single most valuable thing I have worked to improve. We still have a long ways to go, but we went from a place where on a team of roughly twenty developers with many active projects would constantly have to ask "Who has the latest code?" to a place that practices disciplined code management.

When I first started, my jaw almost hit the floor. I couldn't believe that no one actually knew how the source control worked (at the time TFVC). It is hard for me to explain just how bad things were. There were instances of features completely disappearing from production because some one never checked in the code.

Check-ins were at best months a part and production versions of code were scattered on different people's PCs.

After a long, long time we have most developers on board with good practices. There are still some who refuse to follow industry best practices, but our team, and the products we create have a much higher quality.

C1: I was the person with attention to detail. One guy built the system and led things. I spotted cracks in it, and patched it to be stable, then proposed a better system when they needed one.

C2: I was the "living documentation" for the entire system. There was plenty of docs, gigabytes of it in fact. Too much for most developers to know by heart. My job was to actually read it all and answer questions. I'd bring up things like how this portion is not optimized according to this specification here, or that portion is missing error handling N, which happens frequently, or this other server fallback is not being used. The system has millions of daily active users, so every time an API is called twice, that costs serious money. I'd also spot things like unstable hacks that were hidden in the code by some old programmers.

C3: Whole code was a mess. I spent half my time refactoring it, which also meant a few late nights sometimes, and chopping out thousands of lines of code a week. It cut down maintenance and bugs drastically. Where one thing would require 4 hours to do, it then required 10 minutes.

Convinced the CEO to fire the founders.

I make sure I'm up for _anything_. Give me that thing that has been the thorn in everyone's side. Yes, some rather daunting (read: frought-with-peril) tasks present themselves, but... if done well, usually yield a better 'next assignment'.

Not necessarily limited to development roles, I feel like in every team/company, there are these pesky sources of friction that everyone has sort of learnt to live with because in the short run, taking the few extra steps to work around something is usually quicker than facing the actual problem. Actively push to remedy these, whether it's something you can take care of yourself in a few hours/days, or you need to campaign to get someone's buy-in. It goes a long way - not only in time saved, but also in mental capacity freed up.

This can be code, build systems (or lack thereof), missing automation, or even lack of clarity between various stakeholders.

At a previous employer, we had an incident management bot that was pretty widely used by product teams but for whatever reason, the actual data just sat in a Redis instance (the default Hubot adaptor out of the box) and was never looked at

The data was mostly a mess as the bot had interfaced with Flowdock at one point and later Slack, but even then Slack had undergone a few changes to the message schema. All up, there were about 4 different distinct schemas.

To be clear, what was stored was the representation of an incident that also included data about the person who commanded the incident. Generally the commander data was just a copy of their profile data, and that was the thing that mostly changed over time.

Anyway, one of my first tasks when I joined was to throw together a small web API to expose that data so we could generate reports and what not.

Perhaps the most important thing to note is that nothing I did actually drove any particular change. I just got lucky because when our new CTO joined and started asking product teams how many incidents they often had, product teams started asking our group for reports.

Seeing how much time my manager was spending generating these things, I took the next logical step of throwing together a basic UI (filtering, sorting, exporting to CSV) so that it inverted the overhead onto the teams themselves rather than it being bottlenecked by one or two people doing reports.

Anyway, there's more to it than that, and funnily enough no one in our wider team was really aware of what I put together. Having said that, it was a fun experience and kinda nice getting a little bit of attention for a while. It was more or less a side project so I got to field customer requests (and treat users like customers), balance priorities and so on

I guess the theme here would be a mix of visibility and automating toil?


I've often thought about doing a New Old Thing style postmortem on that bot. It was rewritten a little while ago now but the first version, using the default hubot adaptor, made me really appreciate Redis. It was doing some highly uestionable stuff under the hood but as a testament to Redis, it never missed a beat.

I organized a cookie swap. There are dozens of process improvements and internal efforts that I've had success with but the cookie swap is my favorite story. Without some culture, work is work.

I would love to exchange browser state with my coworkers and act as them for a few hours. I think I could really clean up our ticketing system if I was logged in as someone who could outright delete tickets instead of merely marking them as closed.

Worked for a SaaS that took in sales data and generated customer surveys. There were a few things I did 1. Create an easy way for support to login as a different user so that they could see what the customer sees. 2. Created a report that figured out how often each customer sends data and noticed when they were 2 standard deviations away from their average data send. We went from customers calling upset that their data is not up to date to us calling them and letting them know that they stopped sending us data.

I'm primarily focused on automated testing. Which is great but all revolves around test data "fixtures", standardized test data that is integrated with the system under test to be sure all the tests are using correct data.

My company is large, and coordinating all this data was typically done over email or jira.

I designed and built a test data API service with a web UI, now in heavy use across many departments and three business units.

Increased pricing. Making more money per customer helped reduced the load and which helped provide a better service and it also helped get better customers.

Take ownership and fix issues, make this a habbit and do it often, not a one-time situation. Depending on your role this can be code level, architecture, people related, hiring, manual processes, etc.

The best signal is the thing most people are frustrated with but never seem to find time to get to.

As you move up in your career you will be faced with more difficult problems and challenges, especially those with no clear answers or path to follow.

A long time ago, I convinced a company to put floor-to-ceiling white boards on every wall of a conference room.

A not so long time ago, I convinced developers to use the automated QA system as part of their development process. The QA folks had automated almost everything, so it was much faster to test by submitting a QA job. Moreover, QA owned the metrics around performance goals, so developing to the test meant fewer surprises.

When I started at a previous company, we scored almost 0 on the Joel Test. (Remember that?) By the time I left, we were at close to 100%.

Its only one google search away but ...


You're welcome.

Pushed for everything to be code checked into source control. The application code, scripts, tools, migrations, documentation, alerts, tests are all code artifacts that get versioned, reviewed, scanned, deployed, executed automatically. Working on infrastructure still.

Decide and communicate the metrics that matter for your business, then constantly educate and remind engineers of how they can help to reach those goals. Increases the number of good ideas from people with the best context and reduces the bridges-to-nowhere.

Be careful on this one. When not done well it quickly leads to people optimizing for metrics rather than outcomes. It's also a quick path to dark patterns.

Yes, it has to be done extremely carefully. Picking metrics well is one of the most important jobs of company leadership.

Figuring out where the most time is wasted. About 1/5 of my job is chasing SQL queries that didn't get run in some environment. I keep pushing for active tracking of which queries have been run where to try and eliminate that.

I was in the same boat about 10 years ago. I wasted time confirming that sql scripts were deployed to different production databases. I needed to chase down logs and contact dba's through email, etc... It was a big time-waster.

My team created a standard adhoc script template to help with this. The goal of the template was:

1) confirm script is deployed to the correct database 2) inserts record into log table (start date, end date, description, etc...) 3) updates log table when script completes / fails

We asked the script runners / dba's to reject any script that doesn't use the standard template. They reviewed and contributed to the template and were totally onboard.

The majority of our script writers use sql prompt, which allows for sql snippets - so everyone is used to starting out with this standard template as they write these scripts.

No issues since we implemented this. And I can confirm when and where scripts ran quickly.

Specifically, performance optimizations and reliability improvements. More generally, applying my most unique and valuable skill set compared to the people I work with and advocating for good design decisions toward those ends.

Improve the culture. Processes, tech stack, productivity, these are just tasks. If there is a culture of continuous improvement then those tasks are always being improved. Better is not a destination, it is the journey.

I resigned.

A note of sympathy here, as people in sibling posts seem to be seeing this choice in a negative light regarding the resign-er's self-worth or competence. Leaving can be a powerful expression of "I have tried my best, hung on as long as I can. I love this place, and I love what we do, but I cannot stay. Something is broken."

It can be a hard choice, but one that sets an example for your colleagues: there are some situations which a person cannot abide ad infinitum.

If the situation pushed you so far as to resign, then you made an important choice.

Everyone is in charge of ONE thing at a time. That thing being the most important thing that will make everything else easier. The One Thing is a good book.

We implemented a customer support software, it was a game changer. It resolved most of the chaos.

Could you say more about this? Is this an initial screening flow that formalizes customer support requests, a self-discovery tool, etc?

We used a tool called Freshdesk in which sending an email to a particular email id creates a support ticket. Also you can reply from it's dashboard. We had b2b customers who used to send a lot of queries everyday. This tool helped in distributing queries among the team. Earlier it was only one person mostly who was handling all queries, thus was overwhelmed. Also it has auto rules which can be used to set priority to the tickets. Very useful tool when you have a sizeable number of customers. It helps in providing better customer service also as very few tickets go unanswered .

would love to learn more about how you're using Freshdesk and the types of queries you're responding to! I'm building a customer support app that uses openAI's GPT3 to generate automated responses and it's been working great so far!

How can I reach you?

I do something every day that no one else is doing for the clients.

Fully automated a process that I had zero domain knowledge on.

Introduced async Slack stand-ups, introduced containerized artifact-based deploys, massively reduced scope and time of several engineering projects by relaxing constraints (uptime, generality, etc)

Gain a lot of capital.

I left.

Fire early, fire often.

It's risky unless you can protect yourself from Machiavellianism (willingness to manipulate and deceive others), Narcissism (egotism and self-obsession), Psychopathy (lack of remorse and empathy), Sadism (pleasure in suffering of others)

Well duh, literally everything has risk though. Your comment is effectively useless in my opinion as it adds nothing to the conversation of improving a company, you're just stating it's risky. It's risky to even get out of bed to get a coffee as you are required to manipulate people to do so! Even worse than that, you have to manipulate an entire logistics chain to get that fresh cup of joe. Just ignore that these are all free exchanges and that those poor manipulated people get paid for the work they choose to do and can tell you to piss off at any time they please.

Pot. Kettle. Black.

This is true, but I see this kind of self-protection and political awareness as just another career skill. Too many people try to avoid it instead of acting against it. Or sometimes you can ignore what the company does and focus on your own craftsmanship.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact