Ask HN: What were the things you did that made the biggest impact at your work? - <AUTHOR> It could be a tool that you have created, a process that you have started or anything else which created a big and lasting impact on your workplace.
For me, it was probably starting holding regular tech book review sessions.
Over time the discussion around both architecture and implementation details got way more structured, quicker and more satisfying to all parties.
Seems obvious, but building up mental model of software development through a structured approach is better than just letting it happen naturally during work hours. <comment><USER2> 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.

<comment><USER3> 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!

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

</comment></comment></comment><comment><USER5> 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 :)

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

Every so often, after a system restart due to running out of battery on my laptop, I'd start Firefox and get the dreaded "only one window, home tab".

I was able to recover by going through backups, but it was a fiddly and manual process, and for a while last summer it happened annoyingly often. There were a couple of times I couldn't recover what I'd been working on the previous day.

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

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

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

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

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

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

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER10> 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.

<comment><USER11> how can you tell they're attentive?

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

</comment></comment></comment><comment><USER13> 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. :(

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

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

Maybe a different way to look at it is: if you could shorten the BTD loop to a minute or two, why _wouldn't_ you want that?

<comment><USER16> I would have less time to legitimately read Hackernews!

</comment></comment></comment></comment><comment><USER17> 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.

<comment><USER18> You'd love _The Unicorn Project_ if you haven't read it. I highly recommend it, and it's a story around roughly the same journey.

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

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

The gist of it is that reducing your time-to-production is one of the best investments you can make. It changes everything about how you build things.

</comment></comment></comment><comment><USER20> 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.

<comment><USER21> For user facing documentation, always ask Karen in accounting to read through it and provide her opinion.

</comment></comment><comment><USER22> 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.

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

</comment></comment><comment><USER24> 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.

</comment><comment><USER25> 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.

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

<comment><USER25> Indeed, doing successful rogue projects enhances your job security. Unsuccessful ones, though, watch out!

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

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

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

</comment></comment></comment></comment></comment></comment><comment><USER28> 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.

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

</comment></comment><comment><USER29> 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 :-)

<comment><USER30> For anyone curious about using something like this technique, Facebook has a similar tool.

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

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

</comment></comment></comment><comment><USER31> 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.

<comment><USER32> > opportunity to write new tools for front line support staff

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

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

</comment></comment></comment><comment><USER33> 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)

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

</comment></comment><comment><USER35> 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

</comment><comment><USER36> 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 :)

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

</comment></comment><comment><USER38> "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

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

<comment><USER40> Quick! No time to get in the car, hurry up and push!

</comment></comment></comment><comment><USER41> 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.

</comment><comment><USER42> 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.

</comment><comment><USER43> 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.

</comment><comment><USER44> 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.

<comment><USER19> What were the critical, actionable metrics?

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

</comment></comment></comment><comment><USER45> 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.

<comment><USER46> Why do you stay if you are compromising your values on a daily basis?

</comment></comment><comment><USER47> 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.

</comment><comment><USER48> 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.

</comment><comment><USER49> 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.

</comment><comment><USER50> 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.

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

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

<comment><USER50> Asking someone else to take a risk is a very good insight.

</comment></comment></comment></comment><comment><USER52> 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.

</comment><comment><USER53> 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

</comment><comment><USER54> 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.

</comment><comment><USER55> 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.

<comment><USER56> 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?

<comment><USER55> 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!

<comment><USER56> Thank you, that's so helpful! This is a really great idea

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

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

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

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

</comment><comment><USER58> 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.

</comment><comment><USER59> 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.

</comment><comment><USER60> Having two dry erase boards with various colored fine tip markers on hand

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

<comment><USER60> invaluable tools -- a computer needs a stack, a human needs a pad

</comment></comment></comment><comment><USER61> 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.

</comment><comment><USER62> 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.

</comment><comment><USER63> It often seems like shutting down potential acquisitions has the biggest impact, but it's hard to get credit for saying "no" to something.

</comment><comment><USER64> 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.

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

<comment><USER64> Some people simply have to make a name for themselves

</comment></comment></comment><comment><USER65> 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.

</comment><comment><USER66> 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.

</comment><comment><USER67> 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.

</comment><comment><USER68> 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.

<comment><USER69> If you'd care to share more details about this test, I, and I'm sure others, would be interested!

</comment></comment><comment><USER39> 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.

</comment><comment><USER70> Man, I know _exactly_ what I did that helped this, and it's _so_ dumb, but I know it's made a difference.

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

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

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

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

</comment><comment><USER71> 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.

</comment><comment><USER72> 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.

</comment><comment><USER73> 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.

</comment><comment><USER74> 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.

</comment><comment><USER75> * 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

</comment><comment><USER76> 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.

</comment><comment><USER77> Resigning.

</comment><comment><USER78> 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.

</comment><comment><USER79> 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.

<comment><USER80> 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)

</comment></comment><comment><USER81> 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.

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

</comment></comment><comment><USER83> 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.

<comment><USER84> 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?

<comment><USER85> I believe that is their portal/intranet. Each employee has profile there and these would be badges for that area.

</comment></comment></comment><comment><USER86> "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.

</comment><comment><USER87> 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.

</comment><comment><USER88> 100% Discovering and using Karabiner.

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

<comment><USER89> As someone who recently switched from Fedora to OSX for work reasons this looks _amazing_.

</comment></comment><comment> code-is-code Doing API-first.

Start with defining the swagger.json Then generate:

\- frontend-typings

\- frontend request services

\- backend routes and DTOs

\- database fields

\- use angular-jsonform for forms

\- use the swagger for frontend validation

\- use the swagger for backend validation

\- use the swagger to discuss api changes with the client

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

<comment><USER90> How though? All of the swagger open-api tooling is REALLY bad or abandonware. Did you write your own?

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

</comment></comment></comment><comment><USER91> 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.

</comment><comment><USER92> 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.

</comment><comment><USER93> 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.

</comment><comment><USER94> 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

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

</comment></comment><comment><USER95> 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.

</comment><comment><USER96> 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.

</comment><comment><USER97> 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.

</comment><comment><USER98> 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.

</comment><comment><USER99> 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.

</comment><comment><USER100> 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.

</comment><comment><USER101> 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.

</comment><comment><USER102> 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.

</comment><comment><USER103> 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.

</comment><comment><USER23> 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?

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

</comment><comment><USER105> 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.

</comment><comment><USER106> 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.

</comment><comment><USER107> I found a simple and light screencapture tool and I record my coding sessions into reasonably-sized videos.

<comment><USER108> Could you share the name of that tool?

<comment><USER107> It's just a couple of shell scripts:

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

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

</comment><comment><USER110> Saved a million four in a little under a minute with a SQL query last year.

Know your tools. Know your environment.

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

</comment><comment><USER112> Staying home (from an "open office" design) and working there.

</comment><comment><USER113> Documentation

Automation

</comment><comment><USER114> Promoting experimentation and rapid deployment.

</comment><comment><USER115> Quitting.

</comment><comment><USER116> Getting enough sleep.

</comment><comment><USER117> got treated for attention deficit, pi

</comment><comment><USER118> 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.

</comment><comment><USER119> Quitting.

</comment><comment><USER120> 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.

<comment><USER121> I don't understand this. Care to elaborate?

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

<comment><USER26> 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.</comment></comment></comment></comment>


Fuzzing the .NET JIT Compiler - <AUTHOR> https://mattwarren.org/2018/08/28/Fuzzing-the-.NET-JIT-Compiler/ <comment><USER2> > Or in other words, a fuzzer is a program that tries to create source code > that finds bugs in a compiler.

This is a very narrow definition of a fuzzer. There are a lot of types of fuzzer that do not generate source code, and are not intended to test compilers.

<comment><USER3> When I was an undergrad in 1997, I created a fuzzer (well, we didn't know to call it that back then) to insert one byte changes into Java classfiles, and then used that to test our bytecode verifier along with Sun and Microsoft's.

Suffice it to say, we found lots of bugs, the most famous one being what my grad advisor called the vacuum bug that could read a web client's environment variables (among other things): [https://archive.nytimes.com/www.nytimes.com/library/cyber/un...](https://archive.nytimes.com/www.nytimes.com/library/cyber/under/072397under.html)

<comment><USER2> Very cool! I think fuzzers are SO interesting. One of my favorite examples is lcamtuf's post on generating valid JPGs from nothing [1]. Just so awesome.

1: [https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of- th...](https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin- air.html)

</comment></comment></comment><comment><USER4> I wonder, instead of an AST-generating fuzzer, if they could have used AFL on an instrumented binary that may find more possibilities since it just works on paths and bytes without being constrained by what this fuzzer knows are certain constructs.

<comment><USER5> Can you easily run AFL on .NET (or jitted) code? My understanding was that AFL works by instrumenting paths taken and kinda needed a gcc-produced binary with normal Linux debug symbol stuff.

<comment><USER6> What AFL needs is _instrumentation_ and of course the easiest way is to get that at compilation step, _however_ you are not constrained by anything to get that part via other means. Check [https://github.com/ivanfratric/winafl](https://github.com/ivanfratric/winafl) that uses DynamoRIO.

So, to answer your question -- it wouldn't be easy but it can be done.

</comment></comment></comment><comment><USER7> An obvious next step to consider might be applying EMI techniques: [https://mehrdad.afshari.me/publications/compiler- validation-...](https://mehrdad.afshari.me/publications/compiler-validation- via-equivalence-modulo-inputs.pdf)

<comment><AUTHOR> Thanks for the link, I'd not heard of EMI techniques before, they look interesting

<comment><USER8> If you're interested, here's a collection of resources on compilers correctness (testing & fuzzing, validation, and verification): [https://github.com/MattPD/cpplinks/blob/master/compilers.cor...](https://github.com/MattPD/cpplinks/blob/master/compilers.correctness.md)

</comment></comment></comment><comment><USER6> Great article. Kudos.

On a side node, my old project [https://github.com/dyjakan/interpreter- bugs](https://github.com/dyjakan/interpreter-bugs) along with short presentation I did on WarCon 2017 [https://github.com/dyjakan/conference- talks/blob/master/2017...](https://github.com/dyjakan/conference- talks/blob/master/2017-WarCon-Interpreters-Under-Pressure.pdf) (references might be interesting for others).

</comment><comment><USER9> Nice use of Beyond Compare for the side-by-side IL snapshots.

<comment><AUTHOR> I'm glad you liked that! (I spent more time that I should've trying to show that in a meaningful way and I was pretty glad when I remembered about 'Beyond Compare')</comment></comment>


Cassini to image the Earth tonight  - <AUTHOR> http://saturn.jpl.nasa.gov/news/waveatsaturn/timezones/

<comment><USER2> _At Saturn 's enormous distance, the crescent Earth, with most of North America illuminated by the sun, will span a single pixel and will appear as a pinpoint of light in the depths of space [1, 2]._ FYI - The Cassini cameras are 1-megapixel cameras, modes include 1024x1024, 512x512, and 256x256 pixels [3].

I work at an observatory and there was some internal discussion this morning about heading outside to wave. Cool idea, but I don't think you are going to be able to see yourself in the image ;)

Times for anyone in the US to head outside:

      U.S. - Hawaii-Aleutian Stand. Time  Fri 11:27 AM 	11:27 	HAST
      United States - Alaska Daylight     Fri 1:27 PM 	13:27   (24/h) 	AKDT
      U.S. - Pacific Daylight Time 	      Fri 2:27 PM 	14:27 	PDT
      U.S. - Mountain Daylight Time       Fri 3:27 PM 	15:27 	MDT
      U.S. - Central Daylight Time 	      Fri 4:27 PM 	16:27 	CDT
      U.S. - Eastern Daylight Time 	      Fri 5:27 PM 	17:27 	EDT

[1] [http://www.cbsnews.com/8301-205_162-57594419/cassini- spacecr...](http://www.cbsnews.com/8301-205_162-57594419/cassini-spacecraft- set-to-capture-pale-blue-dot-of-earth/)

[2] [http://blogs.scientificamerican.com/life- unbounded/2013/06/1...](http://blogs.scientificamerican.com/life- unbounded/2013/06/19/return-to-the-pale-blue-dot/)

[3] [http://saturn.jpl.nasa.gov/faq/FAQRawImages/#q5](http://saturn.jpl.nasa.gov/faq/FAQRawImages/#q5)

<comment><USER3> So I've seen some gorgeous images from Cassini, but I could've sworn they're all much higher than 1 megapixel. Do you have any info for how that works?

<comment><USER2> I would checkout the FAQ page @ [http://saturn.jpl.nasa.gov/faq/](http://saturn.jpl.nasa.gov/faq/)

I am not sure how the Cassini imagery works, but for something like Hubble Space Telescope (HST), here is what a raw image [1] looks like of M51 [2]. Typically the images you see from HST of M51 [3] will be a compilation of dozens of raw images using colour filters.

[1] [http://i.imgur.com/qtQdcBS.jpg](http://i.imgur.com/qtQdcBS.jpg)

[2] [https://en.wikipedia.org/wiki/Whirlpool_Galaxy](https://en.wikipedia.org/wiki/Whirlpool_Galaxy)

[3] [https://en.wikipedia.org/wiki/File:Messier51_sRGB.jpg](https://en.wikipedia.org/wiki/File:Messier51_sRGB.jpg)

<comment><USER3> Thanks :) The links are much appreciated! I have to say, purely from an artistic point of view, there's something a lot more dramatic about the raw images than the final one (at least to my eyes). I think it's a combination of the contrast, and the fact that the object is too big to fit in the frame that gives it a sense of scale.

</comment></comment></comment></comment><comment><USER4> I will be waving. Cuz I'm a dork. But I will actually be waving.

Come to think of it. I might even throw a waving party of some sort. Hold up a sign, have some beer, play some The Blue Danube via Spotify over Airplay.

<comment><USER5> Shine a spotlight in the direction of Saturn, or build a fire. I wonder how much light you'd need to emit to have a noticeable effect? The Narrow Angle Camera is 1024x1024 I think[1], I have no idea what integration time, so my first guess is that we need to get a major city to riot/burn, or start a forest fire. Hmm, on second thought, maybe I'd better just have a beer and wave like cdevroe.

[1] Based on the properties of this image [http://saturn.jpl.nasa.gov/multimedia/images/raw/casJPGFullS...](http://saturn.jpl.nasa.gov/multimedia/images/raw/casJPGFullS70/N00175897.jpg)

<comment><USER6> Not quite the same question, but related - XKCD did a "What If" on whether, if everyone on Earth shone a laser at the Moon, it'd be visible. (TL;DR: No.)

[http://what-if.xkcd.com/13/](http://what-if.xkcd.com/13/)

</comment></comment></comment><comment><USER7> In 2006 Cassini already took a beautiful image of Saturn with the Earth visible: [http://apod.nasa.gov/apod/ap061016.html](http://apod.nasa.gov/apod/ap061016.html)

</comment><comment><USER8> I love the romance of this. Even though the earth is only going to be a few pixels, the frame will contain a snapshot of the entire human race.

<comment><USER9> That's one of my favorite things about the famous Earthrise photo: [http://en.wikipedia.org/wiki/Earthrise](http://en.wikipedia.org/wiki/Earthrise)

The frame contains every living human, and every human who has ever lived - except for three of them.

<comment><USER10> > every human who has ever lived

How is that, exactly? Doesn't the picture only contain the light captured at that moment?

<comment> T-hawk "The frame contains". Meaning that every dead and then-living human was within the camera's view frustum, except for the three in the spacecraft. Not considering whether they're in the nighttime part of the planet or on the far side away from the camera; just that they're somewhere within the field of view.

Presumably many photos of the Earth from spacecraft have achieved the first part of that criterion, as Cassini's will. But the set of photos of most of the human race minus a few is much smaller: limited to the moon missions, because the shuttle and space station orbit too low to fit the entire Earth in one camera frame.

</comment></comment></comment></comment><comment><USER11> Assuming perfect accuracy, how many people would it take aiming standard laser pointers at Cassini during the imaging to noticeably impact the resulting image?

<comment><USER12> Based on XKCD's research ([http://what-if.xkcd.com/13/](http://what- if.xkcd.com/13/)), I am guessing the short version of the answer is, "More than we have."

<comment><USER11> That's hilarious. However, my question involves impacting the optical imaging system of Cassini which is many, many orders of magnitude easier than overcoming direct illumination from the Sun. The real issue is the matter of beam dispersion rather than having insufficient power, as an astronaut 10 meters away could easily blind Cassini's optical imaging system using a laser pointer.

</comment></comment></comment><comment><USER13> I'll wave when they send a bigger camera.

</comment><comment><USER14> I will be waving from WTC (NYC), so hopefully other people will too. 5:27-5:42PM ET. Space programs are awesome!

</comment><comment><USER15> A bummer, saturn is currently visible here, but will be on the other side of the planet when the time comes.

</comment><comment><USER16> Isn't Cassini near Saturn? How is it going to image the Earth? Why are we waving?

<comment><USER17> _> How is it going to image the Earth?_

The sun is being blocked by saturn itself, so the earth will be visible to the camera. The real purpose is to image the rings. Actual info is here: [http://saturn.jpl.nasa.gov/news/waveatsaturn/](http://saturn.jpl.nasa.gov/news/waveatsaturn/)

 _> Why are we waving?_

To ensure NASA's continued funding/for a bit of innocent amusement. Take your pick.

<comment><USER16> Right, so it's going to be far from the street-level imaging Google does, as I suspected.

<comment><USER18> Earth will be a few pixels at best. The pale blue dot photo has basically a single pixel of Earth, though Voyager was farther away than Cassini at the time (past the orbit of Saturn) and its cameras weren't as good.

</comment></comment></comment></comment><comment><USER19> which way is saturn at the moment? if it's only imaging for 15 mins, it surely can't see all of us!

<comment><USER20> I just tried to work that out using a basic app on my phone. My 'calculations' say that Saturn will be to the north east of the moon if you're in the UK? I spent about 3 seconds on this. Can anyone confirm/correct this?

Edit: by north east I mean if you imagine that the moon is on the centre of the map and you look up and to the right from it.

Edit 2: Looks like Saturn will be in the bottom of the constellation Virgo.

<comment><USER19> ah, so I will be in the field of view, if still too small for the horizontal resolution? cool! thanks :)

</comment></comment></comment><comment><USER21> Say 'Cheese', guys!

</comment><comment><USER22> Everyone SMILE! Say cheese!</comment>


Handling Things - <AUTHOR> http://garrettdimon.com/archives/2009/3/31/handling_things/ <comment><USER3> I think that this whole issue was handled completely wrong. Jason should have sent an email to the company first and foremost, and if they didn't do anything about it THEN it would be ok to put it out there publicly.

You have to give the company the chance to right their wrong. It very well could have been an overlooked detail and again it could have been exactly what Jason claimed. However, Jason didn't give them a chance to make it right before attempting to drag their names through the mud.

Heck, even one of the managers at 37s wrote on their comments section that when they have customers complain, they encourage them to send them emails and not post on some site out in the middle of the ether. That is basically what Jason did, instead of complaining about the site to GS he complained about it on his own site where the GS staff had to go and find it. Hypocrasy much?

<comment><USER4> "Heck, even one of the managers at 37s wrote on their comments section that when they have customers complain, they encourage them to send them emails and not post on some site out in the middle of the ether."

Yes, it's hard to do tech support via any third party that sets themselves up as your representative.

"Hypocrasy much?"

Among all the people who talk about honest, transparent communication but are unhappy that this wasn't settled under-the-table...I'd say arguably so.

<comment><USER3> I don't think people are unhappy that this wasn't settled under the table. No one is saying that any of these concerns were unfounded.

But I AM saying that it was irresponsible for 37s not to give GS the chance to rectify the situation before deciding to go ahead and try to ruin GS's reputation. Had 37s first dealt with this privately and then blogged about the outcome, it would have been a MUCH different blog post (or perhaps not if the accusations proved to be correct).

"Yes, it's hard to do tech support via any third party that sets themselves up as your representative."

I would argue that it's hard to deal with any criticism that you don't know exists...

<comment><USER4> "But I AM saying that it was irresponsible for 37s not to give GS the chance to rectify the situation before deciding to go ahead and try to ruin GS's reputation."

GS wronged 37S in a way that was probably legally actionable. 37S has no responsibility to GS to forbear from criticizing them. They opted to criticize and see what GS did instead of starting legal actions; this was generous of them. (Like I say elsewhere on this page, there are some fallacious assumptions being made by those attacking Fried.)

The only irresponsible party is GS.

"I would argue that it's hard to deal with any criticism that you don't know exists..."

Indeed - except that the ultimate complaint is that 37S made their complaint in a venue and fashion that resulted in a lot of people, including GS, seeing it!

</comment></comment></comment></comment><comment><USER4> I think the error here is in remarks like these:

From Croft: "You'd like to think these kinds of companies would be supportive of one another, especially in times like this."

There's an underlying assumption here of some sort of community - or even family - with commensurate obligations. In the eyes of some, Fried has somehow breached a sort of familial allowance, making him the bad guy in their eyes. In the way most people wouldn't generally go first to the police if their teenage cousin stole something from them (but instead work it out among the family), Fried shouldn't have publicly mentioned that GS wronged them, but should have kept it in the family and out of the sight of outsiders.

Except, of course, there's no family here. "Small, web-centric companies" isn't a community, it's just a commonality.

To continue the example above, here's no obligation upon you to cover for some stranger or even acquaintance's theft of your belongings. If you opt to announce where other people can hear you, "Alright, you stole this thing of mine; I want you to bring it back," instead of going to the cops, you've hardly the bully who's handling it wrong - you're being _generous_.

From Dimon: "I think the problem is still the perception that the GS team is made up of fundamentally bad people, and I assure you that's not the case."

The fallacy here, that actions are innocent and harmless unless they're carried out by "fundamentally bad people", is very common and just as harmful. A company (or association, or government, or any organization) doesn't have to be staffed by escapees from Mordor to do harmful and abusive things - nor even outright unethical things.

People defending GS from criticism on the grounds that they're obviously not _monsters_ (for heaven's sake!) miss the point that it doesn't take monsters to hurt other people, even in relatively elaborate ways. Human beings rationalize, human beings justify, and human beings miss the forest for the trees.

Put these two attitudes together, and we get the response that _Fried should have kept things in the family; after all, those GS kids obviously didn't hurt anyone with their peccadilloes._

</comment><comment><AUTHOR> I posted this in the last thread, but the connection here is more clear:

Paul writes in his startup FAQ:

 _"The one book we encourage startup founders to read is Dale Carnegie's How to Win Friends and Influence People. It's critically important for anyone in business."_

If you read that you get that one of the central points is: don't put people on the defensive. Guy Kawasaki in Art of the Start has a paragraph labeled "Wait When You Hate":

 _"Although you should always answer e-mail in under twenty-four hours, there is one case where you should wait at least twenty-four hours before responding: when you're angry, offended or argumentative. E-mail written when you're in these moods tends to exacerbate problems, so delay your response."_

<comment><USER4> I think this would be a more valid point to raise if we were discussing GS's complaints about a cease-and-desist order from 37S.

I also remain a little puzzled at the pretense that Fried's post was some off- the-cuff rant.

</comment></comment><comment><USER5> One of the salient points that seems to be getting lost here is that the damage, at least as perceived by Jason (and to a large extent acknowledged by GS), was done in a very public way. So, simply fixing the problem going forward - as everyone acknowledges GS did, quickly and effectively - <USER2> addresses half the issue from the "wronged" party's perspective.

If you buy Jason's point, this pretty much _had_ to be handled in a loud, public way. On some level, of course, there's no undoing what's done. Certainly a good number of 37s customers who got a bad impression from having their complaints "ignored" by 37s aren't going to notice this blog-spat, and their negative impressions will remain. That's life. But by bringing this to light publicly, and making an issue out of it, at least some of those people _will_ have their impressions corrected, which is only fair.

All that said, could the phrasing have been a little more nuanced and less accusatory? Of course. Was Jason right to assume evil rather than genuine ignorance or lack of perspective? Probably not. (Though it might be reasonable to ask at what point ignorance, when it's so overwhelmingly in your favor, becomes negligence).

But the notion of "37s should have just talked to GS privately, which would have resulted in the same fixes" misses a good part of Jason's argument, which is that a public "offense" (for lack of a better word) ought to be addressed publicly.

<comment><USER6> So I'll actually buy that there are confused 37s customers out there and that a loud blog post will help alleviate that.

But a note AFTER the resolution would have had a similar effect. Something like, "We had an issue with GS-- we thought their language was confusing and, when we reached out, they agreed and made some changes. BRAVO! We've asked them to drop a note to anyone who's posted a question on 37s GS areas to let them know where they can get help if they want to talk to 37s reps. They agreed. BRAVO!"

i.e. do the blog post, but do it after the happy ending.

Does a bombastic blog post get more attention and probably capture a few eyeballs that it otherwise might not? Sure. Would I ensure respect for my newly seeded lawn by savagely beating up the first kid to walk on it? Sure.

Kids and startups make mistakes. Let's be decent human beings when they do.

<comment><USER7> You're giving GS a pass because they are a small startup. If Microsoft came out with a similar service it would have no defenders.

Fried did the right thing by bringing this up in public. Your "BRAVO!" story is naive. If he would have pursued your polite strategy it would have ended in nothing but a sales pitch. That's how GS's business works.

</comment></comment></comment><comment><USER8> Jeff Croft is the only reasonable adult in the whole thing</comment>


A startup search engine using word embeddings and crunchbase data - <AUTHOR> http://www.3top.com/startup2vec/ <comment><AUTHOR> I made this simple search engine. The idea is to later develop a notification service telling me when a new startup come up that is similar to ours.

It is already interesting to look at the results of a search.

I made a README explaining how it work here: [https://github.com/lechatpito/startup2vec](https://github.com/lechatpito/startup2vec)

I wish I could include categories from Crunchbase but those are part of the $5000 a month API key plan.</comment>


How to talk to conspiracy theorists and still be kind - <AUTHOR> https://www.technologyreview.com/2020/07/15/1004950/how-to-talk-to-conspiracy-theorists-and-still-be-kind/ <comment><USER2> In roughly five years, I went from reading _Skeptic_ magazine to believing the CIA killed JFK and traffics drugs into the U.S. to support its black operations, MKULTRA is an ongoing program and had a hand in creating the Manson Family and the Jonestown cult, (rogue elements in) the U.S. government at the very least had foreknowledge of the 9/11 attacks, and pedophile sex trafficking networks are commonplace and widely known among the ultra-wealthy and powerful elite strata of world society.

This happened because of a consistent, observable and undeniable pattern of elite impunity and abuse of power, most blatantly exhibited by Epstein's death in prison (via murder or facilitated suicide), which led me to take a closer look at the holes in many official narratives we're told to accept in place of explanations which imply that the ultra wealthy & powerful exist beyond all law and morality and use whatever means necessary to maintain their grip on power.

When it comes to these matters people are guessing at the truth with the limited picture of the facts available to them, and conspirators are actively poisoning the well by associating good theories with bad ones, so of course the conspiracy theory world is full of disinfo, misinfo, and just plain mistaken takes. But until the bluepilled crowd represented by this article accepts that at the very least _some_ conspiracy theories are true (hell, just look at the history of things which were dismissed in those terms until incontrovertible documentary evidence emerged), they'll be fighting a losing battle.

> It's a defense mechanism: we're primed to be suspicious and afraid of things > that can't be explained.

That's funny. I see the public's need to dismiss conspiracies with mundane explanations as a defense mechanism -- especially the really obvious and undeniable ones like JFK's assassination or Epstein's death. The idea that conspiracy theories represent some source of psychological comfort is just 180 degrees opposite the truth. It's not easy to admit to oneself that your vote is in meaningless in an important sense, that the media you've consumed your whole life is mostly controlled propaganda, and that the avenues to fix these things are risky and uncertain at best.

</comment><comment><USER3> I much prefer MIT's earlier article "How to dismiss that ridiculous plate tectonic theory while smoking a pipe in your office". I think it was published in the 1940s or 1950s. Popular at the time, as I recall.</comment>


Show HN: DocLayer – A modern document editor - <AUTHOR> https://standaert.net/doclayer <comment><USER2> Could you tell me what's modern about it?

If I click "Learn More," instead of showing me a feature list, it shows me a static image with bad formatting and a hard-to-read font.

If the basis of "modern design" for documents is no indentation and a sans- serif font, I'm not too sure I'm interested in it -- I was hoping for something that used layers for versioning or something similarly useful.

<comment><AUTHOR> If you scroll down, there is some more description (I know, the landing page needs work.)

There are a few things that make it better than existing solutions. The UI is much easier to focus in while writing, and is also much faster than existing document editors. In addition, DocLayer works on mobile devices, and allows you to add things like maps, charts, and embeds to documents.

<comment><USER2> I read the description, but none of it actually matches what the picture shows, so it feels like an app that looks harder to use than plain old Wordpad is asking for permission to use my Dropbox account.

</comment></comment></comment><comment><USER3> Could use a lot more description on what this thing does, how it works, etc. You know, things that would convince me whether or not giving yet another application access to my Dropbox account is worthwhile :)

</comment><comment><USER4> I think some more information is needed on the landing page, what makes it new compared to other options? Can it be self hosted? What license is it? Does it require Dropbox? Etc...

<comment><AUTHOR> License is MPL (see github.com/palmerAL/doclayer for more information).

Dropbox is required, because all of your documents are stored in Dropbox. This reduces the costs, security risk, and headache for me.

You can self host - information is in the github repository. (however, your documents are still stored in Dropbox. You could probably modify it, though.)

I do agree that the splash page needs more information, but the page is also targeted to non-technical users that most likely don't want to know the license or if they can self-host.

</comment></comment><comment><USER5> Is this a web app?

And why do the menu buttons sit on top of the text?

It's a document editor, as opposed to a text editor, so can I write my thesis in it? Is it wysiwyg like word, or more compiled like latex?

<comment><AUTHOR> The menu buttons only appear when you hover over the large pink button in the lower-right. I'll try to work on making that more clear from the screenshot.

Is is wysiwyg, and is also a web app.

</comment></comment><comment><USER6> This would be the perfect app to actually showcase on the landing page. If possible.</comment>


UK video games degrees: 95% fail to hit skills target, more CS grads needed - <AUTHOR> http://education.guardian.co.uk/higher/news/story/0,,2287204,00.html?gusrc=rss&feed=networkfront

<comment><USER2> It seems games companies need to stop expecting graduates to already have all the required knowledge and instead train graduates in house</comment>


BackTrack Tutorial – How to crack WEP - <AUTHOR> http://www.luxstock.net/backtrack-tutorial-how-to-crack-wep/ In this Tutorial, I show how to crack a wireless network secured with WEP encryption.This information should only be used for education purposes. <comment><USER2> This is as far as I've gotten in hacking: download aircrack-ng, put my wi fi card in monitor mode, ok, easy enough, but does aircrack work with Vista? have they worked out all the "glitches"? or should I use another program? Maybe I'm just over thinking it...wouldnt be the first time...but after I put my card in monitor mode, then what? start up the cmd line? if so, what do I type in at the cmd line? packet sniffers? (whatever they are...sounds like K9 bomb unit to me)

<comment><USER3> That's not hacking, that's being a glorified script kiddie.

</comment></comment><comment><USER4> Hey, I'm yousing a VMware with back track and I have a problem with I dont know how to solve. I try to do it on my network and it did great, but when I try to do it on my friend network it didnt work and I dont know why. Do I have to clearit first or something?

</comment><comment><USER5> It works fine with me by using the ISO on VMware and I did hack my wireless network with no errors.

Thank you for sharing.

</comment><comment><USER6> Nice tutorial. Backtrack 3 is capable of so much more than just Wireless Cracking witch everyone seems to demonstrate (A bunch of hacker wanna bee's) . In the right hands BT is a very powerful hackers tool and nothing can stand agents its awesome mite ! Nice tutorial

<comment><USER7> I agree

</comment></comment><comment><USER8> EVERYONE that wants to crack someone else's WEP says they want to crack their own, it's kinda like the people that say they buy Playboy 'only for the pictures', or better yet, tell their own doctor; 'I have a friend that....'

</comment><comment><USER3> Someone please kill this thread. Thanks!

</comment><comment><USER9> i have atheros AR928X wireless built in card on my asus laptop, is this supported? i tried airmon-ng but there are no list of my wifi card? please reply help thanks

</comment><comment><USER10> Does someone have tutorial for cracking WPA ?

<comment><USER11> I have found this one for cracking WPA with backtrack. <http://luxstock.net/n1>

<comment><USER10> Thanx .... LOL it's on the same site.</comment></comment></comment>