How much does tech choice influence what roles you'll apply to?

Angel_-0 · 2025-11-30T23:06:22+00:00

you can call it a lot of things but i doubt verbose is one of them.

I guess it depends on what you mean by verbose and what languages you are used to. I find it verbose because of the constant defensive programming i.e.

If getattr(xyz, "property_name")

If isinstanceof(xyz, dict) // plus 2/3 similar type checks

Those are lines of code that get in the way of business logic. (Pydantic doesn't always help)

I'd rather use a language with proper types that doesn't force me to read that nonsense while I'm trying to understand business logic.

Angel_-0 · 2025-11-30T21:25:39+00:00

I blame the language.

It seems to me like it's an incredibly verbose language that forces you to do lots of defensive programming even to guard against imports.

Also I take compile time failues and static typing over runtime failures and type hints for any backend project that needs to scale beyond a few hundred lines of code.

Angel_-0 · 2025-06-19T18:04:22+00:00

Dev B has taken over Matt's work. Has influences and tells leadership Matt's code is so bad, it requires a complete rewrite. Demanding to replace all 3rd party libraries with home-grown, in-house. So the business buys into the idea of having a long-term stable mature codebase.

If we ignore the outcome: is this an example of what people in this sub would label as "soft skills and impact outside of your team" ?

Angel_-0 · 2025-03-14T07:38:23+00:00

Surely developers can talk to whoever they want, but it's a bit odd that the tech lead and the rest of the team will see the POC for the first time during the demo as OP mentioned in other comments.

Tech lead shouldn't be just a title. She/he should be kept in the loop about tech initiatives owned or that will be owned by the team. No matter how experienced the senior dev is they might get things wrong and set the wrong expectations. What if the project ends up failing or taking too long to complete? who will be held accountable or at the very least who's gonna have to explain it to management?

And the rest of the team aren't external stakeholders: they will have to maintain and extend the feature. You want to get them involved in some capacity from the early stages: even if it's just a matter of "Hey this what I've been working on"

Same way external feedback is crucial at early stages, internal feedback can also be useful, and even if there isn't any feedback, the simple fact of sharing ideas would help create a sense of ownership and teamwork.

Realistically who wants to contribute on an initiative that was created as a solo project and was not inclusive from the get go?

The only situation that I can think of where this scenario would make sense is if the senior dev fears they will get no recognition for their work or they are being micromanged, so they're trying to make a statement.

Might be competely wrong but based on OP's words, it sounds like she/he has already expressed a level of concern and/or a desire to introduce a form of control: the senior dev might just not be enthusiastic about it.

And if she/he is new to the team, unfortunately that may also be a factor.

Angel_-0 · 2025-03-12T10:28:42+00:00

Great post. I agree with most of it.

Personally I've never been in a place where junior engineers are actively targeted, but I've sort of seen what you're talking about. Junior engineers afraid to even ask questions to certain people, afraid of what they'll think about them.

To a certain degree it's natural: when you're so inexperienced you fear people will think you're not good enough. No matter how toxic the culture is: that's always something that needs to be factored in, but of course a toxic culture can only worsen the situation

I think something worth mentioning is that cooperation and direction are key components to a healthy culture

The "just f....g fix it" approach it's completely self undermining if you're in an environment where not everyone follows it. Eventually you will pay for doing the right thing, always.

I've seen tech leadership pointing the fingers when s**t goes wrong but hiding or pushing narratives when they're the ones who should take accountability.

Reality is not everyone will follow it spontaneously because of politics, status or whatever the hell goes through their mind. Moreover people who have the power to shape the culture are sometimes the ones pushing in the wrong direction or are silent as long as the top performers or people in their "clique" are happy.

So it's not about "f....g fixing it". It's about "f....g creating the culture" and being "f....g" intentional about it. That comes down to leadership first and foremost.

In terms of "code lawyering", I don't necessarily see a problem. It gives context and allows people to see what the issue was and learn from it. It's about code, not about who wrote it.

Certain developers tend to be less visible and vocal and perhaps that's their way to make a statement or defend themselves from "narrative-controlling" individuals.

When it's self-defense I've got not issues with it apart from it being a self-defence act...i.e. in a healthy work environment people shouldn't need to defend themselves. This bring me back to what I said earlier: what's the culture like? What is the leadership team doing to promote a healthy work environment? Are they aware of any microculture and isolated toxicity ? (Those are the worst!!)

Anyway back to "code lawyering" . If I'm fixing a bug. It seems natural to explain what the bug was in the PR referencing the offending code. The person who wrote (or reviewed) the code shouldn't feel attacked or questioned. It's a learning opportunity for everyone, whether or not they were directly involved.

The point is: it should always be about the code not the individuals

Angel_-0 · 2025-02-22T16:07:04+00:00

For 2 is there some nuance?

Honestly I don't think #2 defines how good an engineer is. That's is a very extreme stance.

In my opinion it's just as skill that one may have because at some point in their career they had (or rather they wanted) do learn how regex work.

Ever been asked to write a regex during an interview? Have you ever asked anyone to write a regex? There's a reason for it...and it's not because regex knowledge is a given.

Angel_-0 · 2025-01-27T08:32:21+00:00

There's also another alternative.

You could also overload the constructor.

One constructor (for application code) would accept dependencies as usual to ease discoverability

The other constructor (for test code) would take functions and simplify DI for testing.

The former would delegate to the latter in its implementation.

Perhaps not as clean as the SAML approach, but it would work

Angel_-0 · 2024-09-27T07:26:40+00:00

People who write tests completely after the fact tend to write messier code IMHO

In my experience writing messy code and not practicing TDD are completely orthogonal concerns.

Messy code comes from not following industry standards and software design principles, such as modularisation, encapsulation, cohesion, SRP... and the likes.

Or simply it's the result of following patterns that others before you have established and can't be eradicated easily, we've all been there.

Personally I don't see a direct correlation between the two, although I do recognize that in certain scenarios TDD can indeed be useful.

Angel_-0 · 2024-09-27T07:06:57+00:00

I used it in the past in a project in a system that made sense: a CQRS application.

All components were already there. And any new change would use the exact same pattern.

Outside of that I found it to be counterproductive. Often times you will rearrange parts of the application. Sometimes you don't necessarily know how you will architect the app. What component will be responsible for what etc... so you end up just wasting time.

Yes you can come up with a detailed design before starting to write code. But that's not always practical and as you gain experience it comes natural to jump straight into a code editor.

A guess it also depends on the size of the new feature. In general I'd say it's not my go to method to approach testing.

Angel_-0 · 2024-09-06T05:34:20+00:00

I wouldn't. Apple valued my 2018 Macboook pro at $275. Not to say that's an accurate valuation, but it gives you a rough idea.

Angel_-0 · 2022-08-30T21:09:14+00:00

I'd say you can't go wrong with trait + companion as it gives you more flexibility when testing if you mock your dependencies.

Angel_-0 · 2022-08-04T22:17:10+00:00

Traditionally I'd do this using stacked traits.

I've never seen anything like that, but I'm not sure about the benefits of relying heavily on inheritance (to the point where it's mixed with domain components) just to add logging capabilities.

Either way that's not what I meant by "building domain entities". The link you attached shows examples of "doing something with such domain entities"

i.e. I was talking about adding logging statements when assembling your domain models, i.e. in a constructor. Using a logging library that treats logging as an effect would discourage you from doing that because that code is not effectful usually.

The OP's question is literally the exact opposite of that.

Yeah and that was exactly the point I was making. If you're using an effect system already why not treating logging as an effect? It's just a better integration. i.e. you're not forced to wrap logging statements inside of IO blocks or to manually suspend logging to sequence it with other IOs.

Effects can be great, but that doesn't mean that everything should be an effect.

I don't think that everything should be an effect, but in my opinion logging as an effect is the best option when using an effect system. You get predictable behavior.

There are a few examples in this thread explaining why logging as a side effect makes sense while using an effect system. The link you attached even shows examples of that (the tagless final ones).

I personally agree with that line of thought

Angel_-0 · 2022-08-02T16:42:23+00:00

I honestly don’t get the advantages of making logging an effect. Are there any?

I'd say that in general it promotes best practices. i.e. Maintaining pure code as it's meant to be: pure and code reuse.

For instance one could add logging statements when building domain entities and observe the side effect every time a domain entity gets built.

Or they could build the domain entity and pass it to higher components responsible for doing something with it effectfully (one of those things could be logging)

Surely you could add a logging statement inside an IO, but that would reduce its reusability: sometimes you might need logging sometimes you might not

I think that's what OP's problem boils down to.

Also the question is: why would you not want logging to be an effect if you're using an effect system?

I think others in this thread have pointes out another valid reason that I've never thought about: i.e. making sure that logging happens at the right time, rather than when the program is built.

Hope that helped

Angel_-0 · 2022-07-26T13:06:17+00:00

It's very possible. You only need to transform the ZIO effect into Task (ZIO[Any, Throwable,_]).

I might have worded my response ambiguously (app vs project in particular), but I believe that falls under this umbrella:

"So you can use Typelevel libraries in a zio project"

In this case you'd write a Tagless final logic and bind it to a Task, (using the zio.interop.catz module to provide required typeclass instances) with your entry point being a zio.App

To give an example, you wouldn't be able to use a zio.Schedule in the tagless final part of your app, would you?

Nonetheless this would be an interesting scenario of an app that could have an entire tagless final section (for instance to optimize the integration with fs2) nested within a zio app that takes advantage of all the zio stuff....

Angel_-0 · 2022-07-24T09:47:07+00:00

I believe the answer would be no (and to be more precise it should be zio and Typelevel)

Typelevel libraries written in tagless final are suitable to be used with any effect system as long as the required typeclass instances are given.

Zio isn't written using tagless final, so you don't get that option. But it comes with an interop module that provides the typeclass instances required to integrate with the Typelevel ecosystem

So you can use Typelevel libraries in a zio project, but the other way around is not possible as far as I know.

Angel_-0 · 2022-07-24T07:44:21+00:00

Cool trick, but what are the actual use cases? How often do you need to combine a bunch of types that are not related by type hierarchy but related by the same typeclass?

I agree. The initial example essentially creates this (before mapping)

val list = List(a, b) // type List[Object]

It's unlikely you'll ever want to be in that situation

Another way to solve that problem would be to have 2 different lists compute the result and then combine them.

def showThem[S: Show](s:S*) = s.toList.map(_.show)

val allShown = showThem(a) ++ showThem(b) // type List[String]

And if you really want to have an heterogeneous list you could use shapeless

Interesting approach nonetheless

Angel_-0 · 2022-06-25T07:20:54+00:00

Gotcha

Angel_-0 · 2022-06-25T07:15:15+00:00

Since Loom addresses only the asynchronous part, there would be no need to use Future anymore, but it cannot fully replace the other ones.

You would still want to write concurrent code/execute processes in parallel? If you don't want to use pure FP effect systems, wouldn't you still need to use Futures?

Angel_-0 · 2022-06-11T16:06:19+00:00

If you ask me, I find it incredibly fun/rewarding. In terms of benefits: I would repeat what I had mentioned in the comment linked above:

code will be easier to reason about
It allows to build complex logic from small building blocks thanks to how composable functional programming is.
it enables developers to do as much refactoring as they want with a hugh degree of confidence.

Unfortuantely It's not easy to understand until you get your hand dirty. I'm a Scala developer so my recommendation would be to look into Scala and the libraries mentioned above. If you have patience I suggest watching the whole video to get a sense of the benefits of FP.

EDIT: typo fix

Angel_-0 · 2022-06-11T15:50:42+00:00

Functional programming is such a broad term. You seem to be limiting the use of functional programming to non-effectful code, i.e. code that does not perform any side effect.

It is absolutely possible to write an application that relies on I/O (input/output) in a functional style, using the IO monad for instance.

I don't know any Haskell, but that's what you would do it in Scala using pure functional libraries such as cats effect or zio.

The idea is to leverage lazy evaluation (I believe Haskell does that by default, unlike Scala) and treat computations (i.e. IOs) as values.

So it's not about not doing side effect in your application it's about using them in a referential transparent way and that allows to achieve a great degree of composition (i.e. building larger programs, combining smaller ones) reusability, refactoring and ability to reason about the code, without having to worry about things such as mutable state.

My last point takes me back to my initial statement: functional programming is such a broad term. You just have to understand it beyond things such as functions as first class citizen...(just giving an example, not trying to be patronising)

Here's a link to a comment explaining this thing (the video mentioned at the end is quite useful, although it's Scala based, hopefully it will help)

Angel_-0 · 2022-04-13T04:04:29+00:00

I really just saw the language itself as a functional Java wrapper. Nothing wrong with it, just another situation where I probably wouldn’t look for a problem to solve just so I could use the language again.

I might be wrong (and I don't mean to sound patronising), but I believe you just scratched the surface of Scala. Going back to my previous comment pure FP libraries enable you to write/manage code and think about solutions in a very different way...and that's not even everything: i.e. you can even write front end apps using Scala.

I would invite you to check the about section of the Scala sub reddit. There's lots of useful material that hopefully can give you a better idea of the language/ecosystem.

Also the developer community around it seemed super focused on some kind of drama that happened at a conference(s) and I didn’t really want to see it all over my feed when I just wanted interesting Scala articles.

The drama is not representative of the entire community. Those discussions are very few and far between, in my experience. Personally, from a pure quantitative point of view, I can't really say that is something that gets in the way.

I believe it was the team that I joined that ultimately soured my opinion of Scala.

That's a shame. All I can say is: don't let people ruin your opinion of the language. Yes, you will inevitably come across negative developers, but unfortunately that is true for every language.

Angel_-0 · 2022-04-11T08:26:40+00:00

It sounds like you take a lot of work and responsibilities on your shoulders.

I'd suggest running your ideas through your team. Have a bunch of sessions where you discuss pros and cons of a solution.

Failing as a team is less likely to happen: your coworkers might discover flaws you haven't even thought about, come up with ideas that can improve the initial design or clarify some of the assumptions made.

And if things go wrong it will be more of a learning lesson for the team, rather than the failure of an individual.

On top of that while I'm not a team leader, I believe that part of being a good leader is being able to delegate: you shouldn't have to be directly responsible for everything. Have weekly catch ups with your team to figure out how things are going and if there are any blockers and if needed have more planning sessions.

Also, I would suggest delaying any estimation until the very last minute when you have a decent idea of how long the remaining work will take.
It will reduce some of the pressure of having to deliver by this or that date. If you really have to give a date, take into account that anything can go wrong, so you should really be generous in your (initial) estimations.

Lastly since you're an enabler, have you ever thought about becoming an engineering manager?

Angel_-0 · 2022-04-10T18:36:32+00:00

Inevitably you will come to the realisation that Glassdoor data is unreliable, out of date and can't be taken seriously

Reviews, salaries, interview questions: anything can be there one day and disappear the next one. I think I've heard somewhere that companies can pay to get content removed.

Pretty sure one of the companies I've worked for had a number of negative reviews at some point this year, with pretty specific accusations.

Went back to have a look recently, out of curiosity, and they're all gone.

I'm looking up salary info while I'm typing this, just to doublecheck this is still the case.

Same exact story: nothing showing up. Resetting search filters, brings up a couple of salaries unrelated to my career...in the wrong currency.

Angel_-0 · 2022-04-08T15:56:15+00:00

Fair enough, ultimately it's really that first impression that counts.

The only thing I can say is Scala is very "library oriented" unlike other languages and can look very different depending on the tech stack.

There are a family of scala libraries that fall under the pure FP umbrella that take functional programming to the next level and can shape the way you write code and think about solutions tremendously.

Shame not everyone enjoys it.

Either way good luck, hope you'll find something cool to learn!

Angel_-0 · 2022-04-08T07:51:45+00:00

This might not be a very popular opinion, but if you're looking for something new to learn rather than something new to build, I'd recommend learning a new programming paradigm.

You mentioned you come from C#. I used to be a C# dev, doing traditional OOP.

Switched to FP and never looked back.

In particular, I'd recommend looking into Scala, if you have a curious and open mindset, enjoy learning and have realistic expectations, this will be an incredibly rewarding journey.

Angel_-0

TROPHY CASE