Ask HN: Who do you talk to about system architecture and design?
Who do you talk to when you have architectural questions? Where do you get feedback on design options? When you want to discuss tradeoffs of those options who do you talk that over with?
I am one of two technical cofounders for a small software company. We have really good discussions about the design of our product. I am pretty good at searching. We are comfortable weighing alternatives and making a decision and living with the consequences. All that said, sometimes I want to discuss with other people some of the design challenges we face, or seek input on how people have approached the problem.
Are there fora that you enjoy for such discussion? It seems that it does not fit with the theme of most Q&A sites. Most IRC channels I know of are pretty focused on their own specific topic.
119 comments
[ 3.2 ms ] story [ 194 ms ] threadI'm curious how often you find that people get actionable information from outside that they couldn't have discovered with better introspection or understanding of the basics. I'm in a similar role and find that people want validation of working systems due to some new person casting shade, have a desire for more exotic technology, or just want people to shoot the breeze with peers on these topics. The answers to their actual problems are often staring them in the face, but are too mundane or boring to accept. Given the pressure to deliver, they'd be better off focusing on the basics for their stakeholders which is the place I try to get them to.
I agree that having a bit more involved discussion will lead to a more informed opinion. From my experience of working as an architect for more than a decade, finding someone with domain knowledge would help a lot if depth is important. A generalist can help validate the design decisions at a high level or suggest alternatives when appropriate.
Some examples we are currently tackling are secret management and rolling out updates. I can easily find products that promise to solve these. I can find some articles about "how we, at $COMPANY, solve this particular problem." If I am really lucky I can find one or two articles that answer "here is what we, at $COMPANY, do, and here are one or two alternatives we did not like for reasons relevant to our context." It is very difficult to find a proper review that lays out common patterns of implementation and gives a framework to discuss tradeoffs thereof.
Likely because any consistent architecture is going to work fine. And the typical developer is writing code with a business need in mind. So it pays to stick to something simple rather than experiment with new design patterns.
This is also a worthwhile thing to keep in mind. Most decisions made right now are likely to not be an issue if they are consistent. That said, it is still nice to know where the scaling and operational issues may arise given these decisions. It is a fine line to walk between over-engineering and just having awareness of things to expect.
(I'm not via The IET either, but could be in theory. That's part of the problem, it's difficult when there's a lack of resources or examples for our discipline - vs. plenty for others. I also sort of think if I managed it it would just be for the letters, it wouldn't actually be helpful or signify anything relevant. It would be nice if there were something to work towards and achieve in that regard that did actually mean something, and motivated working on useful things.)
Isn't that what the IEEE and ACM is for? I'd argue that there isn't a dearth in "professional/academic societies" or "guilds". If anything there are far too many of them. Before you fall into the trap of inventing the umpteenth "all-encompassing" computing guild, like in that XKCD comic, how about trying to address the underlying problem that you'd like to have solved?
I firmly believe that the problem to solve is much closer to facilitating and recording the results of the ceremonies. That is effectively done in part by the above organizations but, in my opinion, the real problem lies with the follow up about implementation inside of the real world. I do think that USENIX is much better at _that_ than the ACM or IEEE.
We have folks talking about their technical challenges at work (myself included). I've seen a number of times someone get unstuck talking through on there.
I think live chat is the best way to work through open-ended questions. Like others have pointed out, non-forum QA sites are (maybe just by choice) not great for that.
Feel free to hang out: discord.multiprocess.io.
https://randsinrepose.com/welcome-to-rands-leadership-slack/
2. Make a blog post and share on HN
3. Let the commenters tell you everything you did wrong and what they would have done instead
Put more seriously—I think if you don't have an external professional network to lean on, then you should blog it, talk at conferences, etc. Saying "we aren't sure this is right but it's what we came up with" will definitely invite comment. Keep an open mind and remember any publicity is good publicity: your harshest critics will still be engaging and giving you feedback.
I don't think chat services (IRC, Matrix, Discord) are a good fit here, unless used to talk to a group of people you already know and have some cachet with. But I might just be old-school.
> 2. Make a blog post and share on HN
> 3. Let the commenters tell you everything you did wrong and what they would have done instead
It's called Cunningham's Law[0]:
> Cunningham is credited with the idea: "The best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer." This refers to the observation that people are quicker to correct a wrong answer than to answer a question.
[0]: https://en.wikipedia.org/wiki/Ward_Cunningham#Law
/meta
The Codeless Code : The Purple Beggar - http://thecodelesscode.com/case/170
> ...
> The monk opened his laptop. “Five separate posters have each called me a blithering idiot and offered a simple solution to my problem, which they claim to have tested on their own systems.”
> Yishi-Shing nodded. “My walk once took me past a beggar whose sign read, You do not DARE throw coins at ME! His body was purple with bruises but his bowl was always full.”
At least I'm not alone. I find the quality of the conversation in random online communities lacking. I toyed with the idea of joining vetted professional communities (paid or invite-only) but I haven't yet. Suggestions are welcome.
I'm not a part of one, but the only community formed online that I've found to last, was one with a weekly video meeting with a few people from the larger community. This actually outlasted the original community.
It's just so easy for any member to become inactive in the community without regular interaction. Free communities on Discord can plausibly be a great option, with the major caveat that the core interactions are over regular scheduled video calls, instead of mostly messages in large group chats.
The C channel was the opposite. Any question was met with "google it" or "we're not going to do your homework for you." If the question was really specific, then the conversation turned to how it wasn't good for discussion in this channel because it was machine dependent.
Specifically I have lived your anecdote. Early aughts, I was in highschool at the time and asked that C channel for some advice building my first 2D RPG game in C (was using BASIC, then Pascal/Delphi before this). Literally got the exact response "we're not going to do your homework for you" when all I was asking was for some direction (libraries etc) + any existing example projects that I could read.
Honestly, I find that most highly technical people are miserable and not very receptive to helping someone learn the ropes. The majority of the peers I've worked with would rather isolate and protect their work, rather than to work collaboratively - and, I 100% get it. I've seen so many people thrown under a bus just for asking simple questions in regards to their solution. Unfairly so.
Also, I have noticed a similar correlation in front-end development. There is a consensus amongst recruiters and decision making that react is the best framework around. First it is NOT a framework ( and it would be better if it was one ), second, it was created 8 years ago when js6 wasn't out yet, and it was addressing a problem since then fixed by native js proxies. Most reactjs Devs are junior, or at best intermediate- but junior, really, since they've only worked with on library all their career, calling themselves full stack engineering, but can't write one SQL query, or cannot write anything else than js.
Those communities are very toxic, because the deliver crap code, they think they are super good and very confident about it, and they absolutely love to trash everyone that disagree with them.
See, you got the elitist toxicity, and the noob toxicity. If I had to choose, I'll run with the elites 100%. At least, we get a hope to deliver.
https://www.youtube.com/watch?v=SxJPQ5qXisw#t=45s
Comments regarding the areas I have expertise in are frequently quite wrong, but worded confidently.
It makes me wonder how wrong comments about other areas are - ones I'm not well-versed enough in to disprove.
For this reason, I don’t think a wisdom-of-the-crowds approach is valid.
I guess my point is be sure to enable paths for those types of roles to exist in your company as it grows - technical leadership that isn't people leadership.
I chose my wording carefully in my question to emphasize discussion, feedback, tradeoffs, and inputs. I do not expect anyone to give me an answer, but I would greatly appreciate being challenged, questioned, and perhaps informed of alternatives. I am also happy to do the same for others where I have worthwhile experience.
The closest thing to commodity information would be an awareness of alternatives/options in a broad category. This also has value, and can sometimes be found. The most common source I have seen for this sort of thing is a cursory overview of the options that a product is replacing in thinly veiled sales copy for a product aiming to solve the problem.
https://randsinrepose.com/welcome-to-rands-leadership-slack/ can be a good resource for talking with folks of diverse experience and backgrounds about architecture.
(IE, be careful before you drink the kool-aide on "cloud" or whatever comes next.)
Also, many blog posts are by people trying to make themselves feel important, pad their resumes, or otherwise self-promote. Tone management in a blog post can make an awful architecture sound wonderful. Other wonderful architectures may be the wrong fit for what you're trying to do.
Finally: Avoid many layers of abstraction. It just adds unneeded complexity to your code and makes it too hard to onboard new hires. Carefully review all 3rd party libraries before you commit to using them. Sometimes introducing a 3rd party library to "save an hour today" will quickly "burn a day, week, or month" later.
There's usually no right or wrong answer - it's all about tradeoffs. I personally prefer to keep the stack and architecture as simple as possible, but many others prefer to rely on 3rd party code as much as possible, regardless of added complexity. Sometimes my choices bite me (I have to reinvent more wheels than I was expecting), sometimes the too-many-layers-of-abstraction approach will bite too (like errors you have no idea why they happen).
Compare different solutions available to the same problem, understand their tradeoffs, and then pick what better aligns to the needs of your project. If you're working with a team, you probably will not be making that decision alone, but the process could be the same.
You can’t beat this type of knowledge. And you learn even more things on the side. I am still blown away by the capabilities of eBPF and what the guy at Netflix does with it for instance. Or stuff like Falco. And if someone (here a devops let’s say) think your are like half bluffing you can show them exactly that you are not. And it also work to spot those that are bluffing and really just read a blog post about it.
Which comes back to the question: better to learn by doing and then you see more the real experts and can lean on them. Or continue yourself to be one.
So ya best way to get knowledge. Like we say there is no free lunch.
Or just use mature solution like Rails for example it solves most of typical problems and has easy itegrations. If you need more flexibility then maybe Node.js or other ecosystem is better.
Generally theme about architecture is called System Design and there are resources to learn it for interviews/learning purposes but most of it only is applicable at very big scale and you might never need it. Read "Designing Data Intensive Applications" and look into [1] if still interested.
IMO better to invest time into data design/querying (caching) so that you won't think you need some vodoo to handle your traffic. Like 90%+ of sites/apps don't have 1000req/second and this should be handled by Python on Arduino so as long as your DB design is good you are fine.
For async processing it's worth taking a look into Temporal [2] as it looks as promising alternative to job ques and cronjobs.
I can also recommend [3] to learn some cloud patterns
[1] https://github.com/donnemartin/system-design-primer
[2] https://temporal.io/
[3] https://docs.microsoft.com/en-us/azure/architecture/patterns...
There's even intro about web services: http://aosabook.org/en/distsys.html
I am slightly frustrated since I can only find web service architecture resources when searching for software architecture on Google...
There's some tricks that's good to know that mostly emerge from language limitations so for novice it's good to learn some language specific patterns:
Then from more stable software except DBs is OS, Compilers and Games: Generally if you understand computation, computers/language and your domain you will come with good architecture. I haven't found any shortcuts yet. Fast iteration wins, so optimise mostly for that and ability to swap stuff that doesn't work, so contain crap as much as you can. Pure functions are by definition swappable and easy to test so abuse that. Use domain commands to mutate stuff and not updateEntity(X) and you will be good. Use turnOnEngine(car) instead of updateCar({ engine: true }). Also learn to use Facade[5] pattern -> this one makes gluing things much safer against abuse (limits API surface).It's also good to know about all the things one can optimise for to take decisions more consciously. So like maintainability, reusability, iteration speed, speed of delivery, observability, security etc.
Generally search for "How to design programs book/course" for more abstract stuff and "$MyLang patters/architecture book" or check blogs of some high profile software or their devs
[0] https://www.goodreads.com/en/book/show/13507787-practical-ob...
[1] https://www.goodreads.com/en/book/show/24514193-node-js-desi...
[2] https://gameprogrammingpatterns.com/contents.html
[3] https://craftinginterpreters.com/
[4] https://computationbook.com/
[5] https://refactoring.guru/design-patterns/facade
A second thought, maybe HN can have a monthly "Let me help you with..." thread where people just post their core skill set for others to leverage. As for me, I am not a programmer but am very fluent in infrastructure architecture. I can speak days/weeks on servers, networking, storage, virtualization, operating systems, etc. Always happy to chat with people, understand their problems, and answer questions relative to my area of expertise.
Good luck.
Clubhouse was awesome for this until they destroyed themselves.
Once upon a time coffee breaks and after work drinks was the most common time these discussions took place.
I would suggest going/presenting at conferences, and networking with the other speakers and form your own network where you can ask questions like this.
AmA
There are probably only 500 CTOs globally who operate at the level of just "budgets and choosing platforms" with another ~100k CTOs who really are de facto system architect. All depends on scale, size of biz, etc.
Beyond being in the boiler room and being a part of a principal engineering community, I basically just do the math and think about it. I also try new things, and I'm building my own architecture at the moment.
The core challenge is that architecture is fundamentally about trade-offs, and it's hard to navigate because we don't share challenges. The essential skill is to solicit a sufficient number of requirements to understand how the trade-offs pull in any direction.
The other thing: there is no perfect, no silver bullet. There can be, however, slam dunks which companies will monetize for specific verticals.
What helped me was to use the experience that I have from aerospace engineering when making architectural decisions, where we have had to budget and do trade analysis on key performance metrics such as accuracy, mass, power, bandwidth and cost. It's been surprising to me when I talk to seasoned developers who recommend various solutions without first asking me about number of users and requests and data sizes I'm looking to serve.
The "hallway track" is a great place to talk to other practitioners about what they are doing, as well as BOF (birds of a feather) sessions. Especially if you can find a conference with an unconference section (like most DevOps days for example), that's another great venue for discussing things.
You'll also get to meet people who you can potentially reach out to directly with questions. It's a great way to build up a network if you don't already have one.