Drunk Post: Things I've Learned as a Sr Engineer • Hacker News Board

Re: Drunk Post: Things I've Learned as a Sr Engineer

#231

Post by repExpMon » Sun, May 30, 2021, 7:58 PM UTC

dmlittle wrote: post #208

anyfoo wrote: post #194

Earlier quoted context omitted.

As I said in another ranty response in this thread, I do not understand how people enjoy spending time debugging trivial issues, that even a simple static type system would just plain tell them at compile time.

I think it depends on what you’re doing. The author of the the Reddit post mentioned he’s primarily working with data systems. I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing. But for long term use cases the static typing guard rails is definitely nice.

> I can see the appeal of someone running quick, ephemeral data analysis not wanting to deal with static typing

I've seen and heard this, (Data science field definitely loves their Python and numpy) but I really believe the common problem of non-reproducible research is partly due to the language choice (and probably more to the root cause - this sentiment in research).

Re: Drunk Post: Things I've Learned as a Sr Engineer

#232

Post by realusername » Sun, May 30, 2021, 7:59 PM UTC

ggregoire wrote: post #179

> The older I get, the more I appreciate dynamic languages. Exactly the opposite for me. I just can't stand hovering a variable or a parameter and not getting its exact type, or typing "." after a variable and not having my editor gives me all the available methods on that variable, or running my code just to discover that it instantly crashes because I made a typo or forgot an argument or passed the wrong argument o…

The ideal for me would be some strong static typing mode for the main code providing all the guarantees you want and some dynamic typing mode for the tests which lets you test everything well.

The main downside for me of the static typing is that it's close to impossible to provide a good testing experience, DSLs, mocks and spy objects kind of require some form of dynamic typing to be usable.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#233

Post by adriancr » Sun, May 30, 2021, 7:59 PM UTC

MaxBarraclough wrote: post #63

eqmvii wrote: post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

It goes too far though. The virtue of simplicity needs to be balanced against the virtue of making proper use of advanced language features. A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code. > The best code is no code at all This can be interpreted as advice to avoid the 'inner-platform e…

> A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code.

They're just the people to read a book on the topic and try to use it everywhere...

Re: Drunk Post: Things I've Learned as a Sr Engineer

#234

Post by runarberg » Sun, May 30, 2021, 7:59 PM UTC

daenz wrote: post #22

eqmvii wrote: post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing because it's so terse. It's been a poi…

Does that matter. A team with a senior/junior separation should have in place a system of peer review where a code not understandable to a peer will not get merged upstream. There would be a CI system with a linter that forbids abusing syntax for writing dense/obscure code. If a code requires documentation there should be in place a doc-coverage tool which forbids new undocumented code from being merged upstream.

If these systems are not in place, and a senior developer can get away with writing overly complex code, then that is the fault of management, not the developer.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#235

Post by giraffe333 » Sun, May 30, 2021, 8:01 PM UTC

Adding on to the thoughts about everyone writing terrible code sometimes, there is also “terrible code makes lots of money”.

Source: over 20 years doing software dev at various companies with terrible code that makes millions. Happily my current job has really great code (imho).

Re: Drunk Post: Things I've Learned as a Sr Engineer

#236

Post by b3morales » Sun, May 30, 2021, 8:02 PM UTC

Tempest1981 wrote: post #16

vageli wrote: post #3

> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…

I've seen lack-of-documentation worn as a badge of honor. "I'm moving so fast, I can't waste my time on documentation. That's the next guys problem." And management is usually/always ok with this short-term optimization.

Also "if the code is clear, it documents itself". Which in my opinion completely misses the point. Good documentation doesn't tell you what the code is doing, it tells you why it's not doing something else.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#237

Post by anyfoo » Sun, May 30, 2021, 8:03 PM UTC

wirrbel wrote: post #226

anyfoo wrote: post #194

Earlier quoted context omitted.

As I said in another ranty response in this thread, I do not understand how people enjoy spending time debugging trivial issues, that even a simple static type system would just plain tell them at compile time.

I mean by now it should be clear to everyone that there are certain trade-offs in the choice dynamic vs static typing. I do like clarity of static type declarations, also the absence of weird polymorphism like functions returning a number or al ist of numbers depending on their parameters, etc. But then, many statically typed code bases are just tested abysmally. It is as if the type signatures would constitute prope…

You do need to write less tests with a static language. The types in your program are proof that your program is correct within the confines of the type system (literally, even in the mathematical sense).

The stronger the type system, the more properties can be proven through it (at the extreme end there are, unfortunately not Turing complete, languages where you can prove every single property--those are more used as theorem solvers however).

Back to "common" statically typed languages, there is still heaps and loads to test, as you say. Not writing those tests is not really the fault of the language...

Re: Drunk Post: Things I've Learned as a Sr Engineer

#238

Post by papito » Sun, May 30, 2021, 8:04 PM UTC

ilrwbwrkhv wrote: post #13

> When I first started, I was enamored with technology and programming and computer science. I'm over it. This is the saddest. One more soul taken by the shrinking of the hacker culture.

Perhaps because we don't feel productive anymore. 90% of the day is meetings, slack, and dealing with production issues because of the unnecessary complexity, then the last 5%-10% of your time is developing - usually involving getting JSON to and from a database.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#239

Post by akvadrako » Sun, May 30, 2021, 8:05 PM UTC

gkoberger wrote: post #203

ggregoire wrote: post #179

> The older I get, the more I appreciate dynamic languages. Exactly the opposite for me. I just can't stand hovering a variable or a parameter and not getting its exact type, or typing "." after a variable and not having my editor gives me all the available methods on that variable, or running my code just to discover that it instantly crashes because I made a typo or forgot an argument or passed the wrong argument o…

I think it's a grass-is-always-greener thing? Early in your career, you lean into one or the other. And then years later, after you're confident you're right, you find yourself trying the opposite paradigm and liking things about it. Both have pros and cons, and if there was a correct answer we'd all just go with that one!

I've switched between the two several times – not out of choice, just because that's what was needed. The order was BASIC, C, Python, Java, Go, Python, with Javascript mixed in the for the past few. I mostly prefer dynamic languages because static typing is just redundancy. The point of programming is to express high-level concepts which can't be captured quickly with types - if you don't understand the concept of the arguments and return types, you are missing the contract. Types can be helpful as the beginning of docs, but that's it.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#240

Post by ecshafer » Sun, May 30, 2021, 8:06 PM UTC

giraffe333 wrote: post #235

Adding on to the thoughts about everyone writing terrible code sometimes, there is also “terrible code makes lots of money”. Source: over 20 years doing software dev at various companies with terrible code that makes millions. Happily my current job has really great code (imho).

How often do we see a collapsed and failed start up where people will say "Wow there was some good tech at that company". Good code and cool code exist on an independent axis as good business plans.