Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

old.reddit.com

Post reply on HN
Print view View original

71–80 of 510 posts

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

#71

Post by pbourke »

whateveracct wrote: post #59
ritchiea wrote: post #56

Earlier quoted context omitted.

I agree with this in principle but in practice code I write that’s quick & easy and not very readable is usually not understandable by me in a few months either. So if it’s a personal project I hope to last I still want to keep it simple with my code.

I'm not saying to hack away and make a mess necessarily. Sometimes the simplest solution also requires learning and building upon other concepts. Or sometimes, a simple interface is written around a complicated core. For example: The OP's quote is used time and time again to argue against FP concepts in industry - a newcomer doesn't know the first principles, so by the OP's folksy razor[1], that code isn't as good as…

> Corporations value the ability to remove all human agency & decision-making from software development where possible.

Corporations value the ability to continue as an operating entity and make changes to the code after the proponent of Kleisli arrows and lenses has departed for greener pastures.

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

#72

Post by adamnemecek »

creamytaco wrote: post #62
sundvor wrote: post #33

Earlier quoted context omitted.

Do it, if only to find Clojure.

Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp. When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche. The best way to discover the essence of l…

What principles are these?

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

#73

Post by qsort »

JKCalhoun wrote: post #42
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.

I don't know. Possibly it's simply because when you accept a career in the thing you're passionate about the thing you're passionate about becomes work. Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come s…

Your second point hits close to home.

It's inevitable, now everyone has access to computers and that means the average audience inches ever closer to the average person.

But boy, it feels like crap to make something I'd never use in a million years.

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

#74

Post by vlmutolo »

dijit wrote: post #65
vlmutolo wrote: post #47

Earlier quoted context omitted.

It's been seven years since I've tried writing any Latin, so you should assume this is butchered. (edit: I think it's less butchered now) codex bonus a discipulo prendatur codex magnus a novo prendatur codex optimus nullus est Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here. EDIT: Forgot a word. Also, I think "prendere" is better for "understood" h…

Antescriptum is probably the closest to the root of the word “pro-gram”.

That's a good find, but I was unsure of whether "program" is semantically equivalent to "code" here. Plus I'm tempted to leave codex since it sounds so good.

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

#75

Post by taf2 »

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.

There is good or bad code - there is only code

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

#77

Post by Mc_Big_G »

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.

Is it "the shrinking of the hacker culture"? I've become an expert in 3 different js frameworks in the last 7 years. Its' fucking exhausting.

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

#78

Post by swader999 »

daenz wrote: post #40
swader999 wrote: post #32

Earlier quoted context omitted.

What is wrong with making it up as you go? I mean everything I've ever built I had a notion of what I was doing but most of the real work was in the details. Anyone could say I was making it up as I go. I'd be like yeah, if I knew completely how to do it, I'd already be finished it. Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Fa…

Nothing wrong with making it up as you go, and I didn't mean to sound like I was knocking it, if I did. Sometimes everyone fumbles around trying to find solutions that work...it's a totally valid way to approach some problems. Sometimes it's a hybrid of knowing what you are doing but not knowing the implementation specifics. You know you need to connect high-level pieces A, B, and C with specific constraints, but it…

Ok this is helpful. If people are doing their own thing and not following the established, agreed on (or even dictated) way or vision, then you need to figure out why if you are the lead.

Maybe it is communication related. Does everyone know that this is the way they should do something? But they still don't? Have you created docs and edicts around these areas? Have you been assertive in code reviews? Have you been proactive and requested design sessions before a lot of work was done?

Has a decision been formally communicated? I see this step not happening enough, people are hesitant to be authoritative after a discussion on architectural concerns. If you are the lead, that needs to happen.

Most of the time it's simply a case of them not knowing how to do it. People are afraid to show their lack of skill and knowledge and ask for help. They get deadline pressure and deliver their default way.

Have you provided a feature or cut through the system that shows this vision for people to follow? Maybe example code, resources on the web that go very deep into the ideas and tactics? Have you paired with them to help them get started or get over obstacles. Perhaps pair your most senior person with juniors for a while to get them on the same page and capable with this vision.

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

#79

Post by Philip-J-Fry »

EMM_386 wrote: post #6

> I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so…

I see where you're coming from, I do all that too. But it's the "jack of all trades" thing. You "know" all that, but do you actually __know__ all that.

I can develop a nice relational database design, write the SQL stored procedures to manipulate it, write a backend API and write the front end SPA for it. I don't think I'm an expert in any of those things though, and if I am then it's more focused on the backend API stuff.

Like, I understand CSS better than most people, but I'm not a guru like some. I can write SQL for anything I need but I couldn't tell you anything about performance tuning my SQL outside of seeks vs scans and the size of a lock.

Understanding the basics of these things isn't really a daunting task and that's why full stack devs aren't paid half a mil a year. But you have to accept at some point that if you're full stack then you're rarely going to be considered an expert in any field. That's not bad though having rounded knowledge is super good.

Post reply on HN