Ask HN: Soliciting critique/feedback for your technical architecture?
Do you post a high level overview online and get the community to provide feedback, or do you rely on friends/co-workers to chime in and provide some insight? The kinds of questions I'd like to get answers to are around something to the effect of "Hmm, your data pipeline should use Kafka and elastic search for XYZ reason instead of RabbitMQ and cassandra for the scale and access patterns you're interested in." "For the fault tolerance you're interested in, erlang would be a good fit" "Here's some other projects/case studies that made ABC tradeoffs that are worth surveying..." Trouble is most of the people I'm surrounded by at work haven't expanded their skills beyond what's expected at the job, so I don't find discussions with them about the architectural possibilities as illuminating as I'd hope.
Are there any reliable ways to get answers to such questions from people who are experienced? Solving different flavors of problems seems crucial to truly level up as an engineer, and I just want to make sure I can get feedback so that I can immerse myself intelligently.
[+] [-] contingencies|10 years ago|reply
[+] [-] bradleyland|10 years ago|reply
In my experience, the challenge with soliciting this kind of feedback is in filtering the responses. Opinions are formed for a variety of reasons. Some are well formed from experience, while others are simply dogma:
Authority Figure X says to use Solution Y.
or cargo cult:
Successful Company X uses Solution Y, so you should too.
It's worth considering why authority figures recommend specific solutions, but that informs you as to the reasons why you should use a particular solution, not that you should always use a particular solution.
Giving a good recommendation first requires that the offerer of the opinion have the qualifications necessary to be considered an authority on the problem domain; second, that they invest the requisite time in understanding your unique set of circumstances; and finally, that they are prepared to set aside any dogmatic beliefs they have developed along the way. You must be prepared to filter the opinions you receive in order to avoid incorporating advice affected by these shortcomings.
Rather that solicit advice on your entire infrastructure, you should do two things:
1) You should seek to understand the technologies you're implementing to a depth that allows you to identify potential pitfalls. In other words, understand what a particular solution is good and bad at.
2) Try to hire/work with people who specialize in specific problem domains. A jack-of-all-trades can only have so much depth.
[+] [-] chris_va|10 years ago|reply
I actually do this for startups, but it's a bit of a specialized and difficult art. Answering specific questions about technology stacks requires having used them before, and most people only have experience with a small subset of them (myself included, so I probably couldn't answer half of your questions). As a result, I often break down the question into phases.
First, broader questions on design are actually a lot easier to answer. For example: "for problem X, should I use a producer/consumer model + sharded key/value or a direct RPC to a search stack?". Or even more open ended: "on this budget, how can I consume the twitter firehose in realtime to do X?".
Second, the more specific "should I use RabbitMQ or Kafka" for my producer/consumer component requires specialized knowledge. Once you break your question down to that level of granularity, though, it is relatively easy to find an expert.
[+] [-] wumbernang|10 years ago|reply
The best critique is surviving production and constant iteration and tackling limits and problems as they become apparent.
If you see a problem, research solutions and hit the cycle again. Sometimes things don't work.
There's not much science in it I'm afraid.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] jobjh797878|10 years ago|reply
Today, for example, I'm going to have a whiteboarding session with one of my employees. We're going to whiteboard the problem we're solving, again, and again, until we both can describe high and low level details in our sleep.
Then we'll do a few searches and leverage other people's experiences to pick our technologies.
The also works for pure architectural discussions. You have a queue between your web server and web workers -- why? etc.
[+] [-] kisna72|10 years ago|reply
[+] [-] iamlolz|10 years ago|reply
[+] [-] fizwhiz|10 years ago|reply
[+] [-] hoodoof|10 years ago|reply
Try posting it to reddit/r/programming too
[+] [-] fizwhiz|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]