Lessons learned the hard way in grad school (so far) - <AUTHOR> https://www.andreykurenkov.com/writing/life/lessons-learned-from-failures/# <comment><USER2> Love this. If I had one to add, don't be afraid to go back to a previous idea with a fresh perspective. I spent several months researching a similarity technique. After making no headway, and realizing that a "crutch" was doing all the work, I dropped the first idea to pursue the crutch exclusively. After many more months, I realized that crutch would not work after all, and was depressed. But then I had a different idea about the original technique. I went back to that, applied the new twist, and eureka!

It is like those old coyote road runner cartoons. The frustrating thing about the coyote was that he never went back and fixed tiny problems with his attempts, instead he dropped every nearly-successful attempt and moved on to something completely different, just to find that it had different bugs in it.

<comment> blaser-waffle > It is like those old coyote road runner cartoons. The frustrating thing > about the coyote was that he never went back and fixed tiny problems with > his attempts, instead he dropped every nearly-successful attempt and moved > on to something completely different, just to find that it had different > bugs in it.

I've heard the same thing about GI Joe. COBRA had working weather satellites ---why didn't they just try again in next weeks episode?!

</comment></comment><comment><AUTHOR> Author here, hope you enjoy! Feel free to ask anything too or suggest revisions.

Disclaimer up front, as I say in the text these are not the only lessons I have learned, just the most directly linked to experiences I can use as examples. And, these are of course applicable to most creative work, not just grad school.

PS there was a pretty lengthy discussion on the /r/ML subreddit already, which you might find interesting ([https://www.reddit.com/r/MachineLearning/comments/fsi7iv/d_l...](https://www.reddit.com/r/MachineLearning/comments/fsi7iv/d_lessons_learned_from_my_failures_as_a_grad/))

</comment><comment><USER3> Has your answer to the question "would you recommend going for a PhD?" changed since you started?

<comment><AUTHOR> Nope! As I said in there, this is inherently in the nature of doing a PhD, and having done research in undergrad and MS I knew that going on. May not make it easier to go through tough stuff, but it does make it easier to not lose desire to do PhD.

</comment></comment><comment><USER4> You write 'fellowship rejected' 3 times, I read 'managed to apply for 3 fellowships'. Just like you did with the paper submissions I think these can also count as successes.

<comment><AUTHOR> Indeed!

</comment></comment><comment><USER5> The biggest mistake I had in grad school (which I didn't survive) was to talk to other people in the department. I was building a parallel discrete even simulator (using an optimistic strategy with rollback). There were a couple of people in the department doing work that needed simulation. I naively went around to them and showed them what I was doing and asked them if there was anything they might find useful. I had read up on the research of the other people in the group, looked at what they were doing and the simulation side was decidedly... um... not robust, shall we say. I identified a bunch of issues that they were certainly having and showed how what I was doing would help them out.

OMG. What a shit storm that caused. My supervisor was thankfully very good about it (I had not cleared my wonderful idea with him). But after a few months of being accused of being a spy and people being cautioned not to talk to me under any circumstances, I decided that industry was the way forward for me. I realised I was not suited for the cut-throat nature of academic life ;-)

I say this knowing that some people will be shocked, but that anybody in academia will be mostly shocked at my naivety. Seriously bad idea, but one that idealistic, younger me thought was natural.

<comment><USER6> A spy for whom?

<comment><USER5> Other professors were convinced I was trying to steal their ideas and give them to my supervisor. It caused him a lot of trouble.

</comment></comment></comment><comment><USER7> Went to college with this guy, great to see him kicking ass on the front page of HN!

</comment><comment><USER8> Good stuff Andrey! Sounds very familiar :)</comment>


Scaling financial audit logs at TransferWise with MongoDB - <AUTHOR> https://youtu.be/ErAlnM-jb9g <comment><AUTHOR> TransferWise is a global technology company that is building the best way to move money around the world and 6M users are transferring more than $5 billion every month with us. All transfers within TransferWise are processed by strict state machine rules handled by "Transfer Service". The state machine has a lot of different states like "New", "Money Received", "Converted", "Transferred", and the Transfer object itself contains the most basic data like source/target values and all necessary IDs of linked domain objects which other micro- services use to execute their part of the processing job. In this talk, I will go through TransferWise transfer flow and show how we scaled the transfer state changes workload - internally defined as transfer audit log - by moving it from a relational #DB to a sharded #MongoDB cluster. I will also go through the JSON "schema" modelling and how we defined the audit log shard key.</comment>


Show HN: Remote teams describe their engineering cultures - <AUTHOR> https://remotehub.io/engineering-in-remote-teams <comment><AUTHOR> If you're planning to join a remote team in a tech role, wouldn't it be fun to imagine how your future life would look like?

You would wake up in your bed, and walk to a coffee machine, and walk to your laptop, and then...

Would you have a daily standup and what time? Would you write words to a Slack channel, or should you physically stand up on a Zoom call? (meaning, should you have your clothes on at this point)

I asked some remote teams to share their engineering habits in the following categories:

\- Daily Standups

\- Pair Programming

\- Agile Software Development

\- Continuous Delivery

\- Open Source Contributor

\- Good For Junior Devs

\- Learning & Sharing

I know there's room for the data to grow, so if you're running a remote team, you too can add your engineering culture – add your company to fill in the details: [https://remotehub.io/hire-remotely](https://remotehub.io/hire- remotely)

If you're working in a remote team (well done!), it would be very nice of you to notify your boss. You'll definitely earn some karma points. I think.</comment>