TL;DR Over the next few years we'll likely see another big shift in software developement industry -> basic app building knowledge will commoditize & another generation of smaller & bigger development centers will pop up. This model is highly inefficient & in majority of cases results in creating crap, but market is unforgiving - demand is just too high, just too crazy. That will be a huge shock for massess of devs who currently rule the market, but are too complacent, too satiated, too happy with just following 1 framework after another & mindlessly accepting concept work of others. Minority will remain on the top, building truly innovative products, staying ahead of boredom, mediocrity & resource-ialization - these are people who understand that technical excellence is not enough & they should focus on building PRODUCTS not just software. You can easily recognize these people, because they keep asking one question: "Why?"

I'm nuts when it comes to feedback. All kinds of feedback:

• on product changes
• development process
• tool applicability
• development agility
• and at last but not least - personal performance as well

Both giving and receiving -> there's no Continuous Improvement loop w/o feedback & there's no high-performance engineering unit w/o Continuous Improvement applied.

I prefer very direct, fact-based feedback (e.g. 1:1), but I won't disregard any other form, as long as the source is trustworthy & reliable.

Right (almost) in my face

Some time ago I've received results of anonymous (well, better that than none ...) feedback poll dedicated to my person & co-operation with myself. Frankly, I don't even know who exactly has participated - all what matters in context of this blog post is:

• these were mainly developers who have limited to high exposure to me ...
• ... but for sure not all of the ones who co-op with me on daily basis

The general outcome was in fact very much on the plus side, but any joy I could have felt due to that has pretty much insta-evaporated once I've realized something else:

Significant group (big enough to confirm that it's not random) have submitted very similar statements that can be summarized as:

"When I come to Sebastian with a problem / question, he does not provide the answer straight away, but describes the theory, presents path of inference, focuses on WHY instead of just answering WHAT (has to be done). I'd prefer a brief, concise answer to my problem, without all the additional clarification."

Frankly, it's one of the worst messages I could have expected to receive. And one of the most disheartening.

Pillars to rely upon

In fact, I do as I do - on purpose. Not because I want to boast with my knowledge / experience, not because I have too much time & no idea what to do with it, not because I like preaching & hour-long sermons make me happy.

Why then?

Platform architecture / product design / conceptual model - these are NOT amalgamates of completely unrelated, random decisions that by chance just feel the best at particular moment. There's always some CONCEPT behind, set of PRINCIPLES, some VISION. To develop & maintain efficiently on such a foundation (this architecture / design / model), whole team has to be aligned (as much as possible) on these principles / vision - understand them, believe in them, find them worth "fighting for" & in the end - embrace them as "theirs".

Each small, atomic (but also - meaningful) decision made on the daily basis is either a derivative of these principles or at least does not contradict any of them (that has to be very clear) - this is why EVERY developer should make understanding them her/his key priority. Otherwise all the decisions (how to name stuff, how to implement particular scenario, where to put what kind of code) will just appear random, so individual developer will not be able to make her/his decisions individually (/independently) with confidence.

Rationale, path of inference, theory behind -> these are not presented for kicks and giggles. It's a part of "organic work", aimed to educate & set a solid foundation that can be later referenced to. If there's a group of people who actually opposes this model of work, I find it (at least) worrisome.

Levelling you up

I expect people (who I work with) getting more & more independent. I want them to learn, I want them challenged. Needless to say, I don't want to leave them alone with their problems, quite the opposite - BUT I'm not going to deliver them the solution on the tray either. I may once, or twice, but that's about it.

This particular pattern in feedback I've got troubles me so much because I find this issue cultural (of engineering culture, not socio-geo-political one) - I expect people to be hungry:

1. for learning (to self-develop themselves)
2. for ownership (to craft something they'll be proud of)
3. for improvement (to elevate their work environment)

I'm not exaggerating - in my project/product development units I don't want ANY people "just doing things they were told to" - what kind of engineering culture it would be?

Each position, each role has to have a clear range of responsibilities (aka level of control) (s)he takes on her/himself and ...

• conceptually understands => therefore is able to identify risks within
• knows justification for => therefore can validate whether something fits in or not
• provides to others via agreed contract => therefore feels responsible for what's provided & its quality

If you're clueless about something on your level of control, your absolutely first priority is to fix this situation. Always. The only difference between various "levels" of hierarchy (full span of Dev positions, leads, architects, CTO) is their level of control - its range (scope) of ownership, granularity & abstraction level of problems faced (not necessarily the complexity - or rather: categories of complexity may be totally incomparable).

That is absolutely crucial to understand for all Software Engineers. If someone prefers the easy-going way ("just tell me what to put here"), what kind of value (s)he provides? Someone has to do all the conceptual work for them & fully monitor their outcomes anyway.

---

P.S.

I expect EXACTLY THE SAME attitude (of Devs) regarding business input -> serious, self-respecting Software Engineer does not accept unquestioningly requirements, expectations or even business feedback: Devs are supposed to contribute to the final product by providing their technical expertise, critical thinking, engineer's pragmatic assessment of the situation. Actual end-product is a mixture of both technical & business perspective (of various sorts ofc) - if one side ain't contributing, product quality inevitably suffers.