Live data from Hacker News

Ask HN: As a developer what are your aha moments?

news.ycombinator.com

121–130 of 189 posts

Re: Ask HN: As a developer what are your aha moments?

#122

Not AHA moments, but some pointers: - most tech is stupid simple, like retard levels of simple, with incredibly complex description - SOA is stupid and monlith is always the way to go(maybe with handful simple microservices) - microservices are not SOA - event sourcing is almost never a good idea - raw bytes over the wire or in storage are not as complex and mysterious as you might think - compiled languages are not…

With bare metal, are you not just paying more for staffing to maintain it? Bare metal as cheaper sounds suspicious. Bare metal as essential maybe if you are doing something like 3D graphics processing or mining or “big data”.

Of course bare metal is cheaper, that is literally the reason cloud providers can be profitable.

Re: Ask HN: As a developer what are your aha moments?

#123
post #116

1. Polymorphism 2. Vendors are often pushing bad architecture 3. Architects often push things for the wrong reasons 4. Companies often push risk to their vendors, avoiding collaboration, inherently increasing risk 5. ORM's hide business logic, preventing a company from understanding its business and adapting to change 6. Relational Databases are an operational anti-pattern 7. Graph databases are excellent tools for c…

How exactly do ORMs hide business logic?

I've seen implementations of ORM's where the complicated joins of relational operations are embedded in the ORM definition. It's done for performance, without considering the impact on future business process review.

This inherently hides that logic from external review.

One of the things we need to enable as architects is to make sure the systems we build are adaptable. Any "framework" that begins to hide logic through efficiencies is bad architecture.

Re: Ask HN: As a developer what are your aha moments?

#124
post #109

You can get paid more and have an easier time. You can’t possibly know what a company you join will be like until you actually have been working there 12 months. For large code bases you can’t really rearchitect anything. You are stuck with how it works. Maybe on small scales you can refactor. Don’t blindly apply design patterns. SOLID is good as a thinking framework rather than a code review gate. Marketing isn’t wh…

> You can’t possibly know what a company you join will be like until you actually have been working there 12 months Does it actually take you 12 months, or did you mean that as a measured, sensible statement? Or are you perhaps looking at it from a bi-directional loyalty or advancement perspective and not just general culture? For me, that would only apply to companies that I interpret as middling/unimpressive at fir…

I don’t see how you can know he team dynamics and politics (all companies have politics) before joining somewhere unless you have a friend working there. And even then what they pick up on might be different to you. I’ve seen a company I haven’t worked for but who was on my radar go from hero company that employees loved to mass walkout not soon after that was bought out.

Buy outs are a big factor plus reshuffles of management and teams.

Not only that, I’ve had excellent vibes at places in the first 6 months to find out the asshole factor is high later on too. Also without any of this stuff just changes, and I don”t see how that is avoidable. Change is constant! MMMV.

Re: Ask HN: As a developer what are your aha moments?

#125

My "aha" moment was realizing most of my ideas and most apps out there are complete garbage. Not needed. Damaging, even. 99.9% of all of it. For example, most "cutting edge" web apps are better off as PHP monoliths. Facebook was a PHP file for a long time. But most apps in general should never make it past being shell scripts, which are better off staying as spreadsheets or better - text files which are better off as…

Where’s the fun in that?

Re: Ask HN: As a developer what are your aha moments?

#127
post #122

Earlier quoted context omitted.

With bare metal, are you not just paying more for staffing to maintain it? Bare metal as cheaper sounds suspicious. Bare metal as essential maybe if you are doing something like 3D graphics processing or mining or “big data”.

Of course bare metal is cheaper, that is literally the reason cloud providers can be profitable.

TCO. Total Cost of Ownership. Bare metal + staffing costs should be compared to cloud + its staffing costs.

Re: Ask HN: As a developer what are your aha moments?

#130
- My team lead showed me code which i wrote just two years ago and i didn't believe at first, that i wrote that crappy.

- When i realized that someone might quit his/her job in his trail phase. It did not occure too me that both sides are checking if its fun/good for them

- The main reason why i'm successful is that, besides my character flaws (which did become better over the last 15 years), good software engineeres are in a very strong demand and when i look on how hard it is to get good people, i just might never have a really hard live

- Softskills are crucial: Taking responsibility, being on Time, being reliable, taking action when it matters without hesitation

- You had a salary negotiation or a discussion and something was decided? You still can get back to this 1-x days later and say 'you know i thhought about it and i'm not happy with the outcome at all. We need to discuss this topic again'

- Don't complain if shit is shitty. Either change it, try to change it, accept it, or quit. Stop telling others thats it shitty and do nothing.

- Estimation is bullshit, never works, never aligns, no one really retrospect it and if you ever find a team where it works, your team gets dismantled for whatever reason and you have to start at 0. Prioritise for relevance, optimize how you work, accept the outcome.

- Never accept a deadline. Without a deadline, your manager can't come back and say 'you promised' which leads to you doing overtime for a misstake your manager did: he/she missmanaged!

- Do less but better. Whatever you do shitty now will come back

- Not doing something because you actually figure out what the other person needed/wanted, is more often then not the better result if it does not to lead writing more code

- Understanding how you programm a computer game for three main reasons: 1. memory allocation can fail 2. how the game loop works and how to programm it 3. Randomness

- Sentences to know:

-- I can try to get it done, but i can't promise

-- I have a date tonight, i can't stay (if they insist:) I have expensive cards for ... (pressuring you into doing overtime just because is missmanagement)

-- No

Post reply on HN