chris_j

Do you mind if I ask where you're from in the UK? I find that there's an awful lot of variation between different regions. For a few years now, I've lived and/or worked in London, where chatting to strangers is not the done thing. But travel to certain parts of the north of England, or Scotland or South Wales, and the norms are much more like what you describe in the US. My father was from South Wales and he loved visiting the States, where he found people to be open and friendly and willing to chat, just like they were where he grew up.

Who is that by and what is the precise title? A quick search didn't reveal a book called "learning microservices" but I may be missing something obvious.

Microservices Patterns by Chris Richardson is a great read. It takes the idea of design patterns and applies it to designing and implementing a microservice architecture. The idea is that you may already be doing some of the things that the book suggests but now you know the name for it and you have some pretty opinionated advice from the author about how to do it. It's a long book but it captured my attention from start to finish and was useful pretty much immediately.

What would you recommend using instead of git?

(Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

It sounds like have come to the conclusion that you can either be taken seriously or you can be open and friendly, as though those two things are in conflict with each other and you need to choose between them. If you _have_ come to this conclusion then be aware that this is not the case. You most definitely can be taken seriously and seen as a leader _and_ be warm and open. It's helpful to view these two attributes as two different dimensions which you can maximise separately.

The book that really helped me with this is The Charisma Myth by Olivia Fox Cabane. It presents a really simple model for charisma as consisting of three components: power, warmth and presence, and gives a lot of advice to help you to strengthen each of those components by doing exercises that work on different aspects of your psychology. The key insight for me was realising that you can come across as both powerful/serious and as warm/compassionate/friendly, and that people who do this are described as charismatic. I genuinely didn't realise that until I read the book - I thought you had to choose between being nice and being taken seriously - and that's why you'll often find me recommending it on HN and elsewhere.

Another book that presents a different but similar model is Radical Candor by Kim Scott. The premise of this book is that you might think that you have to choose between giving candid feedback (including negative feedback) to your teammates or caring about their wellbeing, but that this is not the case. You absolutely _can_ do both and, again, it's extremely valuable to do so.

How does the above sound? Does it address your situation or does it miss the point? I'd be interested to hear any feedback or further questions that you have.

Many thanks. Like the answer to an NP problem it's obvious once you say it but I couldn't for the life of me figure it out.

Ok, I'll bite: What does YCPEATT stand for?

Many thanks. I hadn't realised how good the Algolia search on HN is. I'm still not confident that I've found the one but maybe I've narrowed it down a bit!

The Charisma Myth by Olivia Fox Cabane. The premise of this book is that you can change your psychology to become more of a people person, by cultivating confidence, warmth and the ability to focus. It was recommended by someone on Hacker News six or seven years ago and I wish I remembered who it was so I could thank them. This book changed my life more than any other.

Apprenticeship Patterns by Adewale Oshineye and Dave Hoover: A set of "design patterns" for your career as a software engineer. I read this relatively late on, when my career was in a bit of a rut, and I credit it for giving me the motivation and the tools to get out of that rut. I wish I'd found it earlier.

Other brilliant non-technical books: The Manager's Path by Camille Fournier, Radical Candor by Kim Scott, Mastering Communication At Work by Jon Wortmann and Ethan Becker, Mindset by Carol Dweck, Drive by Daniel Pink, The Power of Habit by Charles Duhigg.

Some brilliant books focussing a bit more on tech and code craft: Growing Object Oriented Software, Guided by Tests ("The GOOS Book") by Nat Pryce and Steve Freeman, Refactoring by Martin Fowler, Clean Code and Clean Architecture by Bob Martin.

I forget where I read it but I heard that this has been a big problem in Microsoft: it's politically easier for a team to get approval to write a whole new feature (to replace an existing one) than it is for an existing team to get approval to spend a significant amount of effort making big changes/improvements. I suppose it makes sense in a lot of ways to work like this but it can lead to situations where a new component doesn't do half the things that the old component used to do. I'd be interested to learn if that really is what happened here.

I haven't used Windows for many years at this point but, back when I did, my taskbar lived on the left (and was set to auto-hide). If I was still on Windows now then losing the ability to move it would be very jarring for me.

That's really fantastic - good work. I'm glad to hear that my experiences with Duolingo aren't the only ones possible.

What results do you find you get from using Duolingo every day for 959 days? Do you find that it's working for you, in terms of gaining better language proficiency?

I ask because I personally became disillusioned with Duolingo's streaks and leaderboards. I found that I was forcing myself to use it every day but I lost the love of learning the language. Ultimately, I stopped using it because I had a lot of extrinsic motivation to hit targets in the app but little intrinsic motivation to keep learning.

It sounds like your experiences were different from mine and I'm curious to learn what made them so.

> I was referring to your (seemingly snarky, and I apologize if I mistook your intent) comment that you hoped I wasn't suggesting to a shared database between services.

Apologies, I did write a snarky comment and I'm very sorry that I did that, rather than asking for clarification and/or explaining my position a bit more clearly.

I take the view that sharing an SQS queue (or a topic, or a stream...) between two services is OK. It creates a contract between those two services, of course, and part of that contract might be that there is a uniqueId field that the receiving service is going to have to persist in its own database in order to only action each request once, but it doesn't add an excessive amount of complexity or coupling between the services, not for me at least.

I'm still not OK with having two services share the same database, though, even if you're using it for a narrow purpose. For me, the danger is that you end up introducing more coupling than just agreeing on a message format and messaging semantics. I've been burned by that once or twice and I don't want to get burned by it again and I'm pretty happy that it's widely seen as an anti-pattern these days and personally I dogmatically avoid it. I do take your point that the database is going to end up being a SPOF/bottleneck, though, and I don't really have a great answer for that in the general case.

I'm not quite clear what you mean by "sharing a single queue between services". If you mean having multiple different services reading from the same queue then no, I wouldn't do that. If you mean having a sending service and a receiving service share the same queue (either directly or indirectly) in the sense that the sender sends a message and the receiver reads it then I can't see any alternative to doing that. If I've misunderstood then would you be able to share what you were thinking of?

I interpret arduinomancer's post above to mean that if the receiving service must action a single message once and only once (which is sometimes but not always necessary) then you need to give each SQS message a unique ID and that ID needs to be stored in as DB by the receiving service. I've used that pattern a few times and it works well (and doesn't result in unnecessary coupling between sender and receiver). In the past, I've used messaging systems that gave stronger transactional guarantees, but those systems were things like JMS or MQSeries and I don't really want to go back to those days.

Use the database directly? I hope you're not suggesting sharing a database between services...

A commit message should ideally describe the intent of the commit. You can read the diff to discover how it was accomplished. They serve different purposes.

I've heard it said that Roman empire finally ended in 1283 with the Norman conquest of Gwynedd, since that would mark the end of the period of uninterrupted Roman rule (assuming one believes that the rule of the Welsh princes descended from Roman rule in Britain nearly a millennium earlier).

The reality is that the decline and fall of the Roman Empire wasn't a sharply defined event and more of a process that took an awfully long time. The idea that lead poisoning contributed to that process is an interesting one but I'm not sure that the article answers any questions about that.

I used to use mocks an awful lot more than I do nowadays. I learned to do that style of testing from the book Growing Object Oriented Software, Guided by Tests (the "GOOS" book, which is still well worth a read, even if you don't subscribe to that style of test driven development). I'm still of the view that mocks are extremely useful if a) you're working in a highly object oriented style (where systems are composed of objects that communicate with their collaborators by method call) and b) you're unit testing relatively small units of code at a time. Mocks are very useful if it's important to you that object X must call object Y, do a computation and then call object Z with the result.

There are two key insights that helped me to eliminate the need for so many mocks: a) modern languages that support functional programming allow you to separate the concerns of computation and interaction with collaborators, and it's an awful lot easier to test drive a pure function that it is to test drive a graph of collaborating objects; b) modern hardware is sufficiently fast that it's much more feasible to spin up a whole service (or many services) in order to run tests on them, and you don't need to write fine grained unit tests merely in order to make the tests run quickly enough.

Understand the importance of having good visibility of your system. Implement good logging and collect metrics, for example the four golden signals of throughput, latency, saturation and error rate. The Google SRE book gives a good introduction to some of these concepts. See for example https://sre.google/sre-book/monitoring-distributed-systems/.

Understand how to load test your system and to reason about its behaviour under load and its failure modes when you push it too hard. It's one thing to be able to build a system and functionally test it such that you're confident that it behaves correctly when you send one request at a time. It's another thing to let thousands or millions of real users hit it for real in production and to have confidence that you are giving them all a good experience.

Many thanks. I feel like I ought to have been able to figure that one out...

Pardon my ignorance; what does RH mean in this context?

I have a Trello board with a "To read" column (along with various other columns for items in my TODO list). If I find an interesting page that I don't have time to read right now, it goes into that column.

The crucial thing for me is to recognise that I won't read everything that goes into that column and that's ok.

Apologies, I only looked at a few examples.

So what do you mean by "retro characteristics" and what do you mean by "a classical style"?

Would it be possible to define what you mean by "retro characteristics"? From some of the examples that you give, it looks like you are talking about modern recreations of classic computers. Is that correct?

It would be helpful if you could give some concrete examples of the sorts of situations where you want to improve your writing or speaking skills. Are you wanting to communicate more effectively at work, in your personal life, or somewhere else? I might recommend a different book depending on the answer.

A couple of books that have helped me:

- The Charisma Myth by Olivia Fox Cabane. This book changed my life than any other. The premise is that charisma is a skill that can be learned, and isn't something that some people are born with, and that you can become more charismatic by working on your internal mental state and learn to emit signals of power, warmth and presence. I didn't used to be a people person until I read this book.

- Mastering Communication At Work by Ethan Becker and Jon Wortmann. This book is specifically aimed at leaders in a business context. It contains lots of great advice on subjects such as understanding different communication styles (and tailoring your approach accordingly), managing your "ethos" i.e. the way that you come across to people, running effective meetings and many more.

As others have pointed out, Slashdot is a classic site. It has been around for decades at this point and it used to fulfil the role that Hacker News does for me today: it was where I would go to see news about tech.

It makes me sad to see that it has gone down hill so much since I last visited. Hacking the back button like that makes me not want to visit again.

I'm a native English speaker who ironically first encountered the use of English as a lingua franca when I moved to London for the first time. London turned out to be a much more cosmopolitan place than anywhere that I'd lived before and I'd say that around 50% of my colleagues at work were non-native English speakers, as were a similar percentage of the new friends that I made. I quite quickly learned to change the way that I spoke in order to be understood, and I learned that certain words that I'd used all my life were not even recognised internationally. The example that I remember vividly: a Polish colleague had to ask me why I kept saying "ta". Where my family comes from, "ta" is short for "thanks" and I had used it all my life without even thinking about it. It was one small example of the things that I had to try to un-learn in order to be understood in the more international environment that I found myself in.

As the article states, many English speakers are monolingual and probably have a hard time empathising with the struggles that non-native speakers can have with a language. I worry that the situation will only get worse. English is now spoken by so many people in so many places and the incentives (and opportunities) for English speakers to learn other languages are consequently increasingly small.

If Wikipedia is to be believed [0], India ranks third in the list of countries ranked by number of English speakers and it's only fair to regard Indian English as a form of the language that is at least as valid as those from other countries.

Having said that, one of the things that you have to learn when you start speaking with English speakers from around the world is to recognise which of the words in your vocabulary will be understood vs which are particular to your native country. I'd put words like "prepone" and "needful" into this category: you need to find an alternative when talking to people from places where those words aren't understood.

https://en.wikipedia.org/wiki/List_of_countries_by_English-s...

> That's interesting. I'm a portuguese language native, and I can relate, but not because we talk like this in portuguese:

The chap in question was from Portugal. If I understand correctly from your website, you're from Brazil, right? Is there any difference between how that word would be used in Brazilian vs European Portuguese?