141–150 of 189 posts
Sometimes using "uncool" technologies and languages is ok, and they often have a good reason.
2. The concept of "innovation tokens" if you solve a business need
https://mcfunley.com/choose-boring-technology
3. There is no silver bullet.
Learned the hard way after switching to the new "flavour of the month"
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…
- whatever cool code you write, if you can't sell it, it is useless
- every dev should work as support tech for some period. then only you understand what your customer needs and challenges in debugging
- Before adopting any new tech, always always look how difficult it is to debug when shit breaks
- keep things simple, so you can have peaceful sleep
- You will never learn everything, accpet this. Learning is continuous process. Just learn to stay curious, that's all.
- learn more and more CS fundamentals instead of getting certs in over-hyped products
- if you want to learn coding, code. don't watch video tutorials.
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…
Spot on ! Agreed with everything ! Some add ons - whatever cool code you write, if you can't sell it, it is useless - every dev should work as support tech for some period. then only you understand what your customer needs and challenges in debugging - Before adopting any new tech, always always look how difficult it is to debug when shit breaks - keep things simple, so you can have peaceful sleep - You will never le…
code can be valuable in more ways than just ‘someone will pay money for this’.
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”.
People always say this as an argument against bare metal servers, but aren't you still have that staffing cost even if you're using a cloud provider? Cloud servers are more reliable than bare metals, but certainly not 100% sla yet. Shit happen regardless of using cloud or bare metal and we'll have to prepare for it regardless whatever type of servers we used.
Most issues I had with both cloud and bare metal servers are usually connectivity issues, which addressed by the vendors or data center operators with me doing nothing but refreshing status page rigorously. I never have hardware issues but it's probably because I always retire old servers after 4 years of operation.
I learned to focus in on just the first compiler error, and ignore all the rest.
Read the first error. Resolve the first error. Recompile. Repeat.
This is just one example of breaking big problems into smaller problems.
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…
> Disgust is the appropriate response to most situations.
Later, in college, we were learning lower level programming details (like what C translated to in assembly and how it managed calls and the stack frame). Despite this being my third CS course in college, I hadn't really grokked recursion yet. But I had a flashback during one of the classes to the TI-BASIC programs I'd written using a stack, and realized I'd recreated recursion (but manually). After that recursion and loops were synonymous in my mind (as they should be, at least in many cases) since I knew how to translate between them. Whenever I saw someone managing a stack and looping until it was empty, I knew both that it could be and how it could be translated into recursion (and vice versa).
It seems to be one of the hardest topics for many of my colleagues (especially those without a CS degree, so lacking practice with recursion) to understand or ever use. But I can usually get them to understand it once I draw a few things out on paper and show the two solutions to a problem (recursive or iterative). This doesn't mean they like recursion, most still avoided it, but they started to understand that it wasn't magic, it was just the computer managing the same data structure they were manually managing.