Was 'scum master' intended?
Software engineering topics I changed my mind on
391–400 of 704 posts
Re: Software engineering topics I changed my mind on
#392Earlier quoted context omitted.
This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer…
Did you know that Java lets you any number of module scoped classes in a single file, just that the public class has to have the same name as the file? There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. Its just that the eco system standards were set by people who thought that having unique class names were super important even though Java already h…
> There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner.
The problem is not "people could use that particular Java feature to make code cleaner, but they don't".
The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere.
And then you have several competing abstractions, and sometimes one gets used, and sometimes the other.
IDEs and type hierarchies help, but only to some degree.
And then you are still stuck with an overengineered abstraction that nevertheless does not allow you to do the obvious thing that needs to be done in your particular case. So you need to implement a fragile workaround, for example copying one of the library classes, modifying it a bit, and then injecting it instead of the one from the framework. All of which will horribly break if someone changes something in the library.
"Style" is never the problem.
Re: Software engineering topics I changed my mind on
#393> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
I agree with the majority of the article, but I feel this is a shallow thought. It really depends on the context as much as the PM. In an agency environment, I love PMs. Lots of the things they do on the developers behalf just aren't in my job description. If I had to do them, I'd get half as much code written.
I think PMs also get a bad wrap, because they are essentially the interface between a developer and the client. When the client is bad the PM can help shield the team from much of it, but ultimately the developers are going to feel the worst of a client through the PM no matter what.
Re: Software engineering topics I changed my mind on
#394Earlier quoted context omitted.
Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…
> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.
I would suggest the difference is if you feel pressure about your response. Is it ok to pass, or say something like "still working on same issue I discussed a couple of days ago"? If not, it's less like a casual conversation, and more like justifying your time.
Re: Software engineering topics I changed my mind on
#395> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements…
The blog you mentioned has interesting articles. Do you have by chance also something similar but for the person on the other side of the desk? I’d like to sharpen my skills to be interviewed. I’m the developer who never has questions at the end.
Always have questions - interviewing is a two-way street. You want to find out what they value, (what's their quality vs speed tradeoff? etc.), and what sort of things they have problems with (possibly something you could solve to really stand out?)
Those are just the most basic and obvious ones. Maybe hard to think of on the spot, but you can think of others in advance and have them ready.
Re: Software engineering topics I changed my mind on
#396Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
Your mention of simple and clean code makes me think of the excellent talk "Transforming Code into Beautiful, Idiomatic Python".
Although it relates to Python programming, if the ideas and principles (and thoughtfulness and pace) from it could be applied to much more written code, then (I think) we as an industry and all our users would be in a better place.
Re: Software engineering topics I changed my mind on
#397Earlier quoted context omitted.
> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so t…
That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck. Natural siloing happens, but you (team) should be striving to reduce it, not encourage it. *More accurately: work can only proceed on that something when X is available*
My point is, it doesn't have to be black and white. If your expert is less available, or has too much of the same work, or you just want a backup, you just start training someone else to be an expert in that area too. It's not costlier than what you propose, it seems that it is always better to start with having a designated expert rather than to dilute the expertise so much than no one really is.
Re: Software engineering topics I changed my mind on
#398> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements…
> Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds Virtually each time I've been interviewed myself the attitude was not to find out what my strengths are, but to discover gaps in my knoledge and skills. I think that's the standard in our industry. Sadly, this is exactly the oposite of what companies should be looking for. Th…
> but to discover gaps in my knoledge
I think I've already found one :)
Re: Software engineering topics I changed my mind on
#399> Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, t…
Unit test that documents the required functionality of code helps a lot. After that, one can refactor the code with all kinds of cleverness.
I'm not sure if I agree with that, unit tests would help document what code does. But it doesn't help when you're reading through code. It's also important to understand how your code does what your unit tests document.
Re: Software engineering topics I changed my mind on
#400Earlier quoted context omitted.
People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin t…
Opinion: but I think "invaluable" is overstating it. I agree with OP: not that important. Again, opinion. (20 years experience here) Edit: I suppose I should clarify why. I think there are more important issues to focus on when building software with others.
I think there might be more agreement here than we think. OP is talking about “people who stress over […]”. I think a linter can be (in?)valuable without stressing over it. Just get everybody on board, don't stress over which style “is better” (as if there's such a thing) and make it your own.