181–190 of 199 posts
I speak Russian and used to read habr.com a lot, which is a Russian-speaking platform where the community members can post on topics related to software engineering, computers, and tech in general. (As you can notice, habr.com have also been trying to gain an English-speaking readers for some time now.) So I read or saw multiple articles in Russian from this specific author. Actually, the one linked in this post is a…
Earlier quoted context omitted.
Couple things about this, because there are levels. First, understand to be a successful engineer you need to be a bit pedantic, so start by forgiving yourself and take a deep breath. Once you become competent enough to identify clean code, understand that your perception of clean code is colored by your own experience and current mental context. As you learn, you will undoubtedly be aghast at your own code that you…
> forgiving yourself and take a deep breath I appreciate the reminder and the helpful tone of your comment in general! > As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago. Just checked, and my code from 6 months ago looks identical to what I write at work. My programming style went through a few different phases but its variability has mostly leveled off sinc…
Is this on the critical path to solving more ambitious goals or just the Sisyphean task you've appointed yourself? It's fine to take pleasure in the small details, and if you want to set up a company to feed that obsession more power to you. However I will go out on a limb and predict two things: 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers and 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
Earlier quoted context omitted.
I have worked with people like the author. They suck. They destroy entire teams and often times the feedback is 99% pedantic personal preferences because why would they do something useful like setup the linter and propose the silly things they always nit pick. These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different…
I'm curious to know if you or anyone else reading this has run into the opposite problem. Or maybe I'm just "that guy" although I am reasonably certain that I am not. As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails. I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to nev…
I think this is par for the course in that subfield.
Part of it is the speed at which things change, both in the software ecosystems and in the change requests to sites. The reliance on comprehensive frameworks (which often need tons of workarounds and glue anyway) also reduces people's desire or experience in actually constructing good abstractions.
Compound this with the fact that startup environments generally don't care about anything other than shipping & pivoting, and want to defer all aspects of longevity.
The same problems exist all over the place, but I think are pretty prominent in these situations in particular.
I speak Russian and used to read habr.com a lot, which is a Russian-speaking platform where the community members can post on topics related to software engineering, computers, and tech in general. (As you can notice, habr.com have also been trying to gain an English-speaking readers for some time now.) So I read or saw multiple articles in Russian from this specific author. Actually, the one linked in this post is a…
The article is actually really useful; it’s a good example of how to not think of code reviews. If you relate to any of the text except for the last three lines, it means you’re reflecting on and running code reviews wrong. A code review is an opportunity for the reviewer to learn about someone else’s coding style and improve it when necessary, and the reviewee to learn their flaws and just how other people see their…
Earlier quoted context omitted.
> forgiving yourself and take a deep breath I appreciate the reminder and the helpful tone of your comment in general! > As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago. Just checked, and my code from 6 months ago looks identical to what I write at work. My programming style went through a few different phases but its variability has mostly leveled off sinc…
> It's simple stuff like putting together a base Modal display component for re-use instead of copy/pasting that div with the inline-styled zIndex of 99,999 for the umpteenth time. Is this on the critical path to solving more ambitious goals or just the Sisyphean task you've appointed yourself? It's fine to take pleasure in the small details, and if you want to set up a company to feed that obsession more power to yo…
I took a look at your github profile and looked through your csv_builder repo project in particular. It's good, clean code. Well done! Given that you apparently understand what clean code looks like, I can't help but feel I may be misrepresenting the nature of the 'bad code' I provided an example for. Let me expand on my modal example and perhaps you'll better understand things.
Here's a snippet from the code I had in mind when I wrote my comment:
I won't go deeper into that because that seems like a pretty air tight assumption, but feel free to let me know if it's an invalid assumption on your part nonetheless.
Now, one might say, maybe he didn't know about the other component? And, in fact, I think this was probably the case. And so I can, to some extent, forgive him for copy and pasting due to ignorance of the other component. It's a big codebase and it's impossible to stay up to date on all changes all the time. Nevertheless, this isn't an isolated case, this kind of sloppiness is the rule in the codebase rather than the exception.
> 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
Good engineers make these kinds of mistakes occasionally, it isn't their default mode of programming. I wouldn't have to worry about micro-management because the need for it, at least of the variety concerning this particular example, would never arise. Surely you understand that bad programming can and does exist?
> 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers
As long as I am responsible for the construction of any kind of software, I will never stop worrying about these kinds of errors because over time they are immensely costly. Team velocity slows drastically due to the unreadable, verbose and repetitive nature of this kind of code. That is unless, of course, the product I'm building manages to embody the vision I have in mind for it and appropriately and sufficiently addresses these kinds of issues such that they are impossible to make anymore. If and when that happens, I will stop worrying because I will rest easy that an automatic process catches these errors and I will be ready to dedicate my brain power to other more interesting problems.
I have no way of knowing exactly how much, but my suspicion is that, in aggregate, sloppy coding such as this likely costs many, many companies building software around the globe millions or even billions of dollars worth of development time every year. I want to alleviate that waste with Pidgin.
And, yeah, devtools aren't exactly the cash cows of software, but they do exist and are occasionally successful. I've got a whole list of SaaS companies in the space, but for brevity I'll simply drop a reference to one I found on HN just this evening. It's called Replay (https://www.replay.io/), and it's a standalone time traveling debugger for web code. They're backed by Andreesen Horowitz, so I think it's likely they have managed to strike on something true.
My aim is for Pidgin to target the process of construction rather than debugging or design as I've seen some other tools do, while still retaining the power of plain text that is invariably lost when using other so-called "low-code" tools.
If you think you might be interested, I would be happy to note your contact details down for when the alpha version is released!
There's something to be said for "Marine Drill Instructor" responses. When the DI is screaming profanities at recruits, [s]he is preemptively saving their lives. The manner in which it is done, is actually a component of the training. A significant part of military training, is to deprecate the individual, in favor of the team. The DI is not an individual. They are the sharp end of the elite organization that the rec…
Still stand by what I wrote, but glad the OP was flagged out.
Earlier quoted context omitted.
It’s possible there are things you are still learning, or context you are missing. You sound still early career enough that the years will likely mellow you out and teach you to better appreciate the ups and downs of building things fast. You know what’s worse than no abstractions? The wrong abstractions.
Oh c'mon graybeard, you can't honestly be defending 1500 line components right now can you? It's not even a matter of abstraction choice, it's a matter of simple hygiene. You know what's worse than the wrong abstractions? Copy and pasting your inline-styled div with a zIndex of 99,999 for the fifth modal in a row because you can't be assed to write a damned display component in anticipation of the next time you'll ne…
Levels to it all. Keep track of painful modules and have strong intent to fix them. Prioritization is a mf.
Earlier quoted context omitted.
It might mean you're doing it basically correct, or it might mean you're touching parts that people don't care about much. The second is probably more common. (It might also mean your team doesn't care about anything any more, in which case look for a better opportunity, unless you want to just cruise along for a while for whatever reason, in which case turn into a bare minimum performer like the rest of your team).…
Thank you! I agree with so much in this, it really strikes the right balance of clean code vs productivity. One of my peeves is a review that points out a bug/incorrectness without offering proof, or suggesting the fix/correct way. The reviewer might observe a code smell, but it's so much better dealt with a question-comment, e.g. "did you try?" vs "this looks wrong". I generally aim to make every comment a question…
But that's not exactly what I meant with question-comments, I sometimes genuinely don't know why are they doing something like this, or have to ask for additional testing/evaluation/analysis/profiling results before I can decide that it's most likely not going to blow anything up. And as long as there's low probability of damage (or rather low expected value of damage) I am happy with the change :)
What really helps is a style guide. It shuts most of those pointless style nitpicks, God I hate them.
Many times, I felt like I had to write code to get through the co-worker's code review, not for the requirement. The requirements to get pass that code review felt inconsistent and vague, so it made work very stressful. Having a conversation with him was a chore as well, as he came off to be very critical even when prepared with questions.
When he left the company, I was not the only one who felt a weight lifted off all of us. No one wanted to put up with that.
Code reviews and other analyses should be topics of open conversation, if anything. They should work both ways and help each other about not only needs but skill development. When it is used as a tool to boost someone's ego instead, it becomes counter-productive and many years later, I sometimes have that in the back of the head, even with those who I know can be attentive towards criticism in code reviews but are otherwise good people.
I speak Russian and used to read habr.com a lot, which is a Russian-speaking platform where the community members can post on topics related to software engineering, computers, and tech in general. (As you can notice, habr.com have also been trying to gain an English-speaking readers for some time now.) So I read or saw multiple articles in Russian from this specific author. Actually, the one linked in this post is a…
I had precisely one boss who was an asshole code reviewer - and the worst is that by then I was a far better programmer than he was, because he was crazy.
(Random example of many - he personally adopted a "foveal coding style" which meant that he pressed return at the first possible moment after 40 characters. Yes, 40. To achieve that, he had a whole glossary of local variable names, all starting with the same prefix, that you needed to learn to read his code - slea, sleb, slec, sled, slee, slef, etc. "sle" stood for serialized ledger entry, except that none of these were serialized and most weren't ledger entries...)
Even knowing he was an idiot, these abusive code reviews were surprisingly hard on me, particularly since I got forced to do a lot of stupid things with my name on it.
I started to get panic attacks, and they lasted for years.
I made a girl cry once with a code review when I was being purely formal - "this cannot work", that sort of thing. Maybe she was somewhat oversensitive, _but_ she was definitely overwhelmed by her new job, and it was not productive! It was just a mistake on my part.
So I am "brutal" and incredibly detailed in code reviews _but_ I'm also friendly and chatty and explain how I have also made that error in the past, which I certainly have because I have made a huge number of errors!, and tips on how to avoid these issues in the future, as well as some sort of programming language suggestion if appropriate.
People seem to really like it. I get a lot of kind words. It makes it much more fun if you see this as a collaborative game whose idea is to get the highest group scope than a competition.
(Also, it's the rare code review that I don't catch some actual bug in the code that would lead to wrong results, and if you point it out nicely, people really appreciate not having to debug that later.)