441–450 of 704 posts
The more you learn, the less you know.
My company started making absolutely perplexing decisions. We were bifurcating everything, in a way that seemed like was set to double our workload for a lot of things. It was under the guise of "being more efficient by having fully independently operating departments." I was pretty vocally opposed to the whole thing, complaining to anyone who would listen, right up until it came out that our department had been sold…
Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…
I had a colleague who was old school and loved optimising, everything he reviewed come back with tiny changes that would save fractions of a ms. His nemesis was a guy who was arguably the best coder I have ever worked with. Things come to a head in one meeting and old school said if we did things his way our code would run quicker and the response was legendary 'If we coded like you it'd run quicker because most of t…
The issue is when you have people who do not code with efficiency in mind, and someone who does think about those things reviews the code.
Most efficiency gains are probably marginal and not that impactful. So you're probably OK ignoring it. And it's true that bringing such things up during code review and then going back and changing it will take more time.
But if people wrote the code with efficiency in mind to begin with they likely wouldn't be spending much more (if any) time while writing the code. Just have to use their brains a lil.
Earlier quoted context omitted.
Maybe not in the U.S. but in Europe, Software Engineering is often a field of engineering where one can get licensed. i.e. in Austria many IT techs and devs are called (at the doctor's office or in formal settings) "Mr. Engineer" ("Herr Ingenieur") if they fulfill some formal criteria and get licensed. A further qualification is becoming a federally certified civil technician for IT (Ziviltechniker or Ingenieurskonsu…
Here's a story for you: I was born and raised in Switzerland, but I live in Germany now. When I first moved here, I was working as a freelancer and needed to register as a sole entrepreneur (Einzelunternehmen, one of the legal entity forms here). Now, there are several types of taxes you pay in Germany based on your income. One of them is the income tax, the other is called Gewerbesteuer (maybe best translated as "co…
As for formal education - I've seen dozens of people with an engineering diploma who barely can write a FizzBuzz, so it is not the best indicator and mostly people don't look at it when it comes to recruitment aside from big corps. Although that kinda changed lately as junior positions started evaporating and without experience the diploma is the main thing they check.
Earlier quoted context omitted.
This is a false dichotomy. On one end, you have "overarchitects everything so much that the code is soon unmaintainable" and on the other end you have "architects the code so little that the code is soon unmaintainable". Always write the simplest thing you can, but no simpler. Finding that line is where all the art is.
> Always write the simplest thing you can, but no simpler. I don't think so. Time and time again the client will insist on stuff like "the customer only needs a single email address/phone number" but you're going to pay for that one later if you do the simple thing and add an "email" column. Same for addresses. And a whole bunch of other stuff...you need to normalize the heck out of your DB early on, even if you don'…
You'll only pay if the project survives long enough for that new requirement to actually surface, which often it won't.
Earlier quoted context omitted.
I had a colleague who was old school and loved optimising, everything he reviewed come back with tiny changes that would save fractions of a ms. His nemesis was a guy who was arguably the best coder I have ever worked with. Things come to a head in one meeting and old school said if we did things his way our code would run quicker and the response was legendary 'If we coded like you it'd run quicker because most of t…
That's just a rude thing to say. If you all coded like him you wouldn't be having the discussion. The issue is when you have people who do not code with efficiency in mind, and someone who does think about those things reviews the code. Most efficiency gains are probably marginal and not that impactful. So you're probably OK ignoring it. And it's true that bringing such things up during code review and then going bac…
Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…
JUST_DO_IT (add value, fast) WHAT_THE_BOOK_SAYS (enterprise arch etc etc)
The BIG problem is the total misconception that:
> JUST_DO_IT = bad engineering
> WHAT_THE_BOOK_SAYS = good engineering
In reality, the quality of execution is independent of the development approach - you can make a complete mess of either approach, however, the WHAT_THE_BOOK_SAYS approach WILL cost you a LOT more time and money to discover your team has messed up it and WILL cost a lot more time and money to fix.
My experience is that, just as your product evolves & grows, your engineering strategy should evolve and grow. There's a good reason why fortune 500 companies will have enormous IT teams, using enterprise cloud technology... and there's a good reason why successful tech start-ups do the exact opposite.... but hopefully, the startup will become a fortune 500 company.
When I was younger, I had an issue with external vs internal validation. Sadly, it heavily skewed towards external validation. I was on the chunkier side for a lot of my childhood and into high school. Joined wrestling and stayed with it. Lot the weight, grew, and gained muscle. Also started to get a lot of attention from the opposite sex. That, with the external validation issue, leaned into it and just had fun. It…
Yeah. I studied psychology and it was the most prominent mind shift for me too. Watching what people do you need to see what is going on in their heads, not the outside things. Looking at a product of someone's work you should see the person who did it.
It completely changed my attitude to discussions. I was a math guy, any statement either true or false, and you need to decide on each one before going further. But now people say things, and I do not see them as things by themselves, I see them as things said by persons. Oftentimes it is completely irrelevant are these things true or false.
Earlier quoted context omitted.
You must have absolutely nailed the rest of the interview!
It was the early nineties. If you've touched a computer, companies would assume that any skill gap you had you could straightforwardly bridge yourself, on the job. It wasn't like today where you have to be a perfect cinnamon roll of a candidate who ticks all of HR's required-skill checkboxes before you can move on to the grueling 5-6 rounds of interviews.
I remember one of my interviews that went well in the end. In the middle of the interview, they mentioned using Java and building web apps. At the time, I was a C++ developer with no web development experience.
I said: "I never did web development," and their response was, "You do know how to write source code, don't you?"
I said: "Of course I do, but..."
They cut me off with: "You will pick it up, don't worry about it."