15 ms·

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

• michaelcampbell 7y ago
  Staying home (from an "open office" design) and working there.
• segmondy 7y ago
  Documentation Automation
• tibbetts 7y ago
  It often seems like shutting down potential acquisitions has the biggest impact, but it’s hard to get credit for saying “no” to something.
• james-imitative 7y ago
  Working as a safety executive at a Widget factory, I introduced automated checking of the sphericality of the widgets we were putting into beer cans. At one point some of the widgets weren't completely round at it was making beer explode in people's faces on very rare occasions. The automated checker was implemented using cPython. ...and as a safety executive at a Widget factory, I have to be really careful who I am aiming my very rare criticisms toward; at times it seems as though people who work in the beer factories that don't put widgets in their beer cans have much lower safety standards than I do, and they get upset at some of the criticisms directed at them. ...that is why we are planning to use Ruby or Scala next time; the other factory workers don't understand that lol. ...I also implemented a "you're working too slowly" message for people who didn't follow their documentation with good authentication practices.
• dharmab 7y ago
  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.
  • Ididntdothis 7y ago
    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.
  • vidanay 7y ago
    For user facing documentation, always ask Karen in accounting to read through it and provide her opinion.
  • chrischattin 7y ago
    I really appreciate people like you.
  • krishna0512 7y ago
    Thanks a lot for your hard work!! It's because of people like you that I have a very good life.
  • rorykoehler 7y ago
    I wish I knew more people who think like you.
  • DerekQ 7y ago
    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.
• Ididntdothis 7y ago
  “For me, it was probably starting holding regular tech book review sessions.” How did you do these so people actually participated? My company is very deadline driven so people don’t really care about learning. Every attempt at regular learning meetings quickly died because people feel they don’t have time. Do you have a specific format? I have led regular meetings about coding style in another company. These went pretty well but in the current company I have failed at instilling curiosity for learning things for its own sake
  • martincmartin 7y ago
    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 7y ago
      Quick! No time to get in the car, hurry up and push!
  • itsArtur 7y ago
    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
• mlurp 7y ago
  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.
• pytester 7y ago
  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.
• javajosh 7y ago
  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. :(
  • insomniacity 7y ago
    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 7y ago
      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 7y ago
        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.
• mitefinedailes 7y ago
  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 7y ago
    What were the critical, actionable metrics?
    • mitefinedailes 7y ago
      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 7y ago
    Possibly you have a bright future in management :)
    • mitefinedailes 7y ago
      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 ;)
• sys_64738 7y ago
  Resigning.
• ferver 7y ago
  Having two dry erase boards with various colored fine tip markers on hand
  • Ididntdothis 7y ago
    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 7y ago
      invaluable tools -- a computer needs a stack, a human needs a pad
• awinder 7y ago
  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.
  • awayfromhomenow 7y ago
    don't leave us hanging!! More details! (please)
  • jwcrux 7y ago
    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-Thriving-ebook/dp/B07QT9QR41/ref=nodl_ https://www.amazon.com/Unicorn-Project-Developers-Disruption...
    • kqr 7y ago
• taptaptapimin 7y ago
  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.
• BossingAround 7y ago
  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 7y ago
    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.
• postit 7y ago
  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 7y ago
    I don't understand this. Care to elaborate?
    • Mike8435 7y ago
      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 7y ago
        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.
• TheMerovingian 7y ago
  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 7y ago
    If you'd care to share more details about this test, I, and I'm sure others, would be interested!
• brayhite 7y ago
  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 7y ago
  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.
• bridgeland 7y ago
  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 7y ago
    This is an interesting idea. How are these emails generally received? Do you have a template[0] that you follow? [0]: https://github.com/kbariotis/templates https://github.com/kbariotis/templates
• jbn 7y ago
  Two things come to mind: 1/ carefully rearranging headers in a large C++ product, cutting build time from hours to 30 minutes. Think levelization a la Viega (see https://www.youtube.com/watch?v=QjFpKJ8Xx78 https://www.youtube.com/watch?v=QjFpKJ8Xx78). 2/ setting up JSP->java->class compilation to detect syntax errors at build time rather than at web server startup, eliminated finding such errors in the field completely.
• lifeisstillgood 7y ago
  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 7y ago
    "Don't call yourself a programmer" - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/?HN_20140807 https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... (2011)
• defnotashton2 7y ago
  * 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
• bedah 7y ago
  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.
• smoe 7y ago
  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.
• zhengiszen 7y ago
  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.
• khalilravanna 7y ago
  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.
  • mavelikara 7y ago
    How big is your team?
    • khalilravanna 7y ago
      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.
  • zaphod4prez 7y ago
    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 7y ago
      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!
• cjfd 7y ago
  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.
• sn41 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
      Not to mention the usage to blinking and moving marquee text to convey important information.
  • phaemon 7y ago
    That is superb. What you're really saying is that 80% of your customers no longer feel the need to phone you.
    • rahimnathwani 7y ago
      "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.
• fersho311 7y ago
  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 7y ago
    Why do you stay if you are compromising your values on a daily basis?
• mmcconnell1618 7y ago
  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?
• gingerlime 7y ago
  Switching my company to remote. It was a gradual process but it worked and now we’re fully remote and everybody seems happy with no exceptions. I can’t take full credit but we also switched to doing 6 week project cycles[0] and pitches inspired by Basecamp. [0] https://3.basecamp-help.com/article/35-the-six-week-cycle https://3.basecamp-help.com/article/35-the-six-week-cycle
  • jacobr 7y ago
    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.
• cpitman 7y ago
  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.
• martincmartin 7y ago
  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.
• nikivi 7y ago
  100% Discovering and using Karabiner. https://medium.com/@nikitavoloboev/karabiner-god-mode-7407a5ddc8f6 https://medium.com/@nikitavoloboev/karabiner-god-mode-7407a5...
  • noir_lord 7y ago
    As someone who recently switched from Fedora to OSX for work reasons this looks amazing.
• marvinblum 7y ago
  Quitting.
• Stronico 7y ago
  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 7y ago
    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.
• Yoric 7y ago
  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 :)
  • kingludite 7y ago
    Oh, thanks!
  • rayuela 7y ago
    This has saved my ass more than I can count. You've earned your bragging rights
  • drywater 7y ago
    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 7y ago
      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 :)
• WhompingWindows 7y ago
  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.
• dyeje 7y ago
  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.
• Cyph0n 7y ago
  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.
• notyourday 7y ago
  Two things: 1. I embraced that Perfection is a mortal enemy of It Works. Our customers pay us for it to work now, not be perfect at some point in future. This allowed us to save millions of dollars a month and made us a viable going concern. 2. "Mongodb is Webscale" - https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs We aren't Google. We don't have Google-level global problems that we need to solve. Anything below Google level can be solved using boring technologies that just work. This allowed us to significantly and rapidly improve customer experience.
• geocrasher 7y ago
  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 7y ago
    > 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 7y ago
      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.
• arez 7y ago
  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 7y ago
    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.
• roydivision 7y ago
  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.
• bertr4nd 7y ago
  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 :-)
  • sevengraff 7y ago
    Interesting, got a blog that goes into more detail?
    • bertr4nd 7y ago
      We wrote this paper about it for CGO: https://research.fb.com/publications/optimizing-function-placement-for-large-scale-data-center-applications-2/ 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.
  • JustAPerson 7y ago
    For anyone curious about using something like this technique, Facebook has a similar tool. https://github.com/facebookincubator/BOLT https://github.com/facebookincubator/BOLT
    • bertr4nd 7y ago
      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.
• tzhenghao 7y ago
  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 7y ago
    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.
• Yhippa 7y ago
  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.
• forgotmypw 7y ago
  I found a simple and light screencapture tool and I record my coding sessions into reasonably-sized videos.
  • kjksf 7y ago
    Could you share the name of that tool?
    • forgotmypw 7y ago
      It's just a couple of shell scripts: https://github.com/potomak/screencapture https://github.com/potomak/screencapture (not mine)
• jodacola 7y ago
  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.
• druidgreeneyes 7y ago
  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.
• debrice 7y ago
  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 7y ago
  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 7y ago
    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.
• cushychicken 7y ago
  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=Cj0KCQiA4NTxBRDxARIsAHyp6gBPb23rsGud9Y0lZtYcS3tKmxuwliSXBDi5UwcBnLVqibwHTMl5FAgaAtg1EALw_wcB 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.
• throwaway13948 7y ago
  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.
• fnord77 7y ago
  got treated for attention deficit, pi
• throwanem 7y ago
  Saved a million four in a little under a minute with a SQL query last year. Know your tools. Know your environment.
• phreack 7y ago
  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.
• k__ 7y ago
  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 7y ago
    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__ 7y ago
      Some people simply have to make a name for themselves
• kingludite 7y ago
  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.
• Arete314159 7y ago
  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.
• vhakulinen 7y ago
  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.
• meken 7y ago
  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.
• f0ok 7y ago
  Quitting.
• mobjack 7y ago
  Instead of arguing about product changes, created a framework to A/B test them.
• ill0gicity 7y ago
  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.
• softwaredoug 7y ago
  I wrote a book in our niche (search), which seems to have done a lot to help our small consulting firm.
• tehlike 7y ago
  Promoting experimentation and rapid deployment.
• WalterBright 7y ago
  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 7y ago
    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 7y ago
      Indeed, doing successful rogue projects enhances your job security. Unsuccessful ones, though, watch out!
      • desc 7y ago
        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 7y ago
          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.
• robbiemitchell 7y ago
  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.
• TeMPOraL 7y ago
  1) Calling out the bullshit. Sometimes politely, sometimes firmly, but when things didn't add up, I'd call them out. Eventually I've uncovered a piece of a product that not only didn't yield correct results, but was unrescuable in principle. As a result, I ended up prototyping and then leading the design and development efforts on a new version that did things right, which eventually became a very strong part of the product offering. (It later turned out that way before I joined, some other people also called the big problem out, but were overruled by someone high up, and after that everyone kind of forgotten that there was a problem in the first place.) 2) At my last job, I wrote a tracing profiler for Common Lisp - or rather, a quick and crude pile of hacks resembling a tracing profiler, now available here: https://github.com/TeMPOraL/tracer https://github.com/TeMPOraL/tracer. Up until then, we had a sense that our performance problems came from the database, but having a hard time pinning them down with regular profiling, we blamed them on the database driver (that we've written ourselves). When we started using the tracing profiler, we quickly discovered that the driver itself was perfectly fine - it's the amount, shape and structure of the queries we're doing that caused our performance to suffer death by a thousand cuts. That couple hours of detour into writing the profiler paid for itself in the following week with an order-of-magnitude performance increase, and the insights gained shaped the further refactoring and redesigning efforts. (Some more details about the profiler here: https://old.reddit.com/r/Common_Lisp/comments/et0fx1/temporaltracer_tracing_profiler_for_common_lisp/ffddyvm/ 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.)
• code-is-code 7y ago
  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 7y ago
    How though? All of the swagger open-api tooling is REALLY bad or abandonware. Did you write your own?
    • kqr 7y ago
      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.
• mdolon 7y ago
  I wrote a little web app to track my weekly goals and check-in with a couple of friends/colleagues: https://weeklycheckins.com/ https://weeklycheckins.com/ It's only been online for a few weeks but it's already been quite helpful.
• cryptozeus 7y ago
  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.
• hkiely 7y ago
  The obvious answer to this question is often increasing gross sales through design improvements. Also, finding correlations with data can also be extremely helpful.
• jecxjo 7y ago
  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.
• orasis 7y ago
  Getting enough sleep.
• deleted 7y ago
  [deleted]
• not_the_nsa 7y ago
  I work in a state govt department. Very simple infrastructure additions have paid out majorly for us. It's my job to innovate around research infrastructure, so the following should be read as outcomes of my role, not bragging. I migrated my division from Word docs on shared drives to Atlassian Confluence Wikis, which made knowledge more discoverable amd accessible. For a work group, I set up a CKAN data catalogue. Soon after, our division adopted it, and after demonstrating it at a GovHack hackathon, I got seconded to our sister agency to build the first production version of https://data.wa.gov.au https://data.wa.gov.au. For a statewide turtle monitoring program, I switched out paper-based data capture with electronic data capture using OpenDataKit. We now have real-time data analysis and reporting. Many colleagues have found a similar need for electronic data capture. Claim to fame: wrote an R package `ruODK` to facilitate data access from ODK to R.
• glandium 7y ago
  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 7y ago
  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.
• thomk 7y ago
  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 7y ago
    Coincidentally, there’s an interview with Tim Cook where he mentions this exact concept when asked about leadership. https://youtu.be/9jhPm_2WYH8 https://youtu.be/9jhPm_2WYH8 24:00
  • volkk 7y ago
    how can you tell they're attentive?
    • thomk 7y ago
      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.
    • muzani 7y ago
      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.
  • reinkaos 7y ago
    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.
• nfriedly 7y ago
  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.
• sevilo 7y ago
  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.
• nojvek 7y ago
  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.
• maddynator 7y ago
  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
• victorpascu 7y ago
  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.
• k4ch0w 7y ago
  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.
• unexaminedlife 7y ago
  "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.
• wurp 7y ago
  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 7y ago
    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 7y ago
      I believe that is their portal/intranet. Each employee has profile there and these would be badges for that area.
• deleted 7y ago
  [deleted]