Hacker News Reader

Comment by dr42 | Hacker News Reader

How very cynical indeed. Speaking as a software architect, sometimes it's important to get people to lift their heads up from the day to day adding value and look at new technologies. Many times developers are so focused on the bug/feature du jour, that they aren't aware there are other ways to do things, possibly better.

Having been a developer for a long time, the thing I have found is how much technology repeats itself, and how at its core, its all very much the same. The same algorithms I have used, like bloom filters or priority queues for example, have application in social networks and 3d rendering engines etc. Having done most software paradigms, an architect us supposed to know which ones work, and when they work.

I haven't written slides or visio in years. Nor have I been to Aruba :)

View on HN

sometimes it's important to get people to lift their heads up from the day to day adding value and look at new technologies. Many times developers are so focused on the bug/feature du jour, that they aren't aware there are other ways to do things, possibly better.

Why can't your developers lift their heads up? Are they just lazy and don't care, or are they overloaded and discouraged from trying new things by the development process and company structure?

Very interesting perspective. I was a developer for over a decade before my path recently started moving towards architect. I find the opposite in my environment than what you are explaining.

We have so many developers working on different projects that someone needs to suggest/enforce some consistency across implementations otherwise you will have 30 projects, each developed in the favorite technology of each team and face resource problems when it comes time for support and maintenance.

To those with more negative leaning comments I would point out that not all development shops are the same. A software architect at my old 8 person startup would have been silly but I don't see how it would be possible to run development and operations of an airline or major finance company without people in this role.

Some of the systems in large IT organizations are vast and span multiple departments and integrate in many ways with multiple other systems.

The expectation that developers should perform their design/dev/test responsibilities while deciding/enforcing consistency across the organization as well as worrying about vendor contracts and negotiations while simultaneously acting as technology's face to the executive office is in my view an unrealistic expectation.

I would hesitate to hire a junior engineer who didn't understand basic subjects like bloom filters and priority queues and when to use them. I certainly wouldn't hire one who didn't know how to research alternative approaches on her own, without guidance from an "architect".

It's not about the ability to research alternative approaches, it's knowing when it might make sense to do so.

an "architect" [sic]

I'll bite. I consider myself a decent developer (but then, who doesn't?). I don't know what you mean by "bloom filters" or "priority queues" without Googling for them. I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research.

Why did you pick those as "basic subjects" for a "junior engineer"? Are they important to your particular area of work?

I'm a micro-optimization and numerics guy by trade (mostly I write math libraries); they are almost completely irrelevant to my area of work.

Priority queues should be covered in a competent introductory data structures course. Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point. They're so widely used that it's pretty hard to avoid learning about them if you've done any significant amount of work or just spend time reading HN (they come up in someone's blog every month or so).

Note that I said "would hesitate to", not "wouldn't hire". If someone were otherwise a strong candidate, but happened to not be familiar with these, I would almost surely still hire them.

I should clarify that a typical candidate for a junior position on my team is either coming from graduate school or has 3-5 years experience in industry. I have correspondingly higher expectations for their background knowledge.

This is just not true.

Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point.

Possibly in your area the candidates you get may have come across them, but then they wouldn't be junior engineers, by definition. If you're advertising for "strong algorithms" candidates then sure, but I bet half the people reading this have never used or come across any probabilistic data structure!

> then they wouldn't be junior engineers, by definition

I don't think so. My impression is that junior/senior is defined by years of experience more than technical skills. Having been out of university for one year now, I know I sure as hell won't get a job as a "senior engineer" anywhere, even if I could easily implement both these structures.

I've been working as a software developer professionally for 20 years and I only came across bloom filters a few weeks ago.

Those aren't basic at all, and I'm not sure why the commenter considered them so. As we all know, junior engineers have very limited exposure to a small area of tech, that's the very definition. It might just happen to be that the dev just finished a CS degree and is great at some of these algorithms, but that doesn't translate into a wide spectrum of technologies, which is only found in people with many years experience.

I was the one that actually picked those, just out of thin air to illustrate my point.

This I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research. is exactly my point. How would you know that a bloom filter might be the best solution unless you know of it's existence in the first place. An architect's role is to suggest areas of research to junior engineers, who very likely may only have some vague memory from algorithms class.

> How very cynical indeed.

I got a real kick out of this part, thanks. I'm imagining a scrawny, somewhat aged nerd-type but with a monocle flying off his face. Hilarious.

Anyway, this is pretty much the same thing architects always say, but where I work the ideas for technologies they play with come from "normal" devs like me. Like, RabbitMQ wouldn't even be on their radar unless someone less experienced told them about it.

I know how the "adding value" thing can come off like hard-nosed cowboy coder nonsense. But in truth, we lowly plebeian devs are capable of writing code and keeping apprised of new tech at the same time.

A good architect doesn't pretend to have a monopoly on ideas or trending technologies. Their job is to make sure that the really good ideas aren't ignored and get adopted more broadly.

Reply on news.ycombinator.com