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

The Best Programming Advice I Ever Got (2012)

russolsen.com

Post reply on HN
Print view View original

231–240 of 247 posts

Re: The Best Programming Advice I Ever Got (2012)

#231

Post by AnAnonyCowherd »

0db532a0 wrote: post #207
AnAnonyCowherd wrote: post #95

I got hired at a Fortune 250 to rewrite a system, from the ground up, that had been running for 5 years. I rewrote it in about a year and a half. Huge success; 1000 happy users. What I learned over time was that "the" person responsible for the group that was _supposed_ to be writing this sort of software in the company had been trying, for 10 years, to make something like it, with a whole team of contractors. In fac…

What was your strategy in one-to-ones, and what would you have changed?

I suppose someone would say that I could have been more diplomatic, but someone needed to voice a differing opinion. Unfortunately, there was just no way -- diplomatically or otherwise -- I was going to be allowed to influence the culture or the process. Too many other people had built their careers on the back of a 30-year-old process. It was, as they say, entrenched. Sometimes, you just get dealt a bad hand, and you can't draw into a winner.

Re: The Best Programming Advice I Ever Got (2012)

#232

Post by thr0w__4w4y »

(background: my expertise/degree is microprocessor design and digital logic, although I've done a butt-load of firmware in C and C++ in my career)

One time (long time ago) when I worked at Motorola (this was back pre-2K when working at Moto actually meant something). There was a systems level problem, and I was brought in as a systems engineer to diagnose a problem (think "big system with tons of FPGAs, fiber optics, embedded CPUs, firmware, etc.)

Pretty soon I delivered my suspicion that the real issue was a hardware problem (this after looking at network data on a capture)

The hardware director said (I wrote this down in a notebook, I'm quoting verbatim): "I stake my career that this isn't a hardware problem. It's either a firmware problem or a misunderstanding of the requirements."

It was a hardware problem. I demonstrated it a few weeks later and the chip vendor confirmed it (it could take up to 2 weeks to reproduce the problem)

After that my name was shit. That's when I learned that office politics are very fucking real, and sometimes you have to decide if you want to be a lifetime corporate employee.

I left less than a year later, hung out a shingle as a consultant and life has been great since then.

You can try to bend the world (or your employer) to your will, but it isn't going to end well. If my life goal had been "work for Moto for 40 years then retire", that wouldn't have worked out so well, for multiple reasons.

I'll always bet on myself before I'll bet on BigCo. I'm contacted every month on LinkedIn by Google, Amazon, etc. (I've trained lots of their employees) and my answer is always the same: "thanks but no thanks"

Apologies if this sounds self-aggrandizing. 100% not the intention. Just a lesson that you gotta look out for yourself, and the real world is complicated. Own your career, don't put it in the hands of BigCo. BigCo doesn't give a shit about you.

Re: The Best Programming Advice I Ever Got (2012)

#233

Post by Viliam1234 »

hueving wrote: post #164
haxorito wrote: post #148

Earlier quoted context omitted.

Answering all questions. One thing i left off is the reason why I was in hot water: Everyone in our organization is really “rank-orientated”, I challenge their intellect and their baby they were proud of - it was foundation for our organization to even exist in company. Even though it was outdated, poorly designed system, that produced high percent of outages and heavy on maintenance. But it was not my place or posit…

It's also possible your solution wasn't as elegant, maintainable, or as performant in all cases as you thought. If you're going to approach upper management with such a hostile attitude, you need to run it by some peers first to have them poke holes in the idea and get onboard. Why I called your approach hostile: you phrased it as "challenging their intellect". That's not how good engineers pitch changes.

> It's also possible your solution wasn't as elegant, maintainable, or as performant in all cases as you thought.

That usually doesn't result in being called to HR and asked to remove everything from one's computer.

Re: The Best Programming Advice I Ever Got (2012)

#234

Post by Viliam1234 »

rocky1138 wrote: post #94
squarefoot wrote: post #92

Earlier quoted context omitted.

"People will sabotage things simply because they want the useful idea to be theirs." Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday. 1. Get a contract. 2. Sell some crappy software to the customer. 3. Wait for them to ask for more speed. 4. Complain it's their fault because their hardware is too old. 5. Offer to either instal…

The way capitalism is supposed to work is you quit this job and open a shop which does the same thing as the existing company but doesn't artificially reduce speed, using that as a competitive advantage. The end result is that the first company is required to either adopt your strategy or fail, either solution leading the consumer to a better result.

> quit this job and open a shop which does the same thing as the existing company but doesn't artificially reduce speed

That would require rewriting the whole application (without the artificial speed reduction part), which may be a lot of work.

Re: The Best Programming Advice I Ever Got (2012)

#235

Post by Viliam1234 »

BeetleB wrote: post #11
alexashka wrote: post #4

All it reminds me of Steve Jobs saying A players only want to work with A players. B players hire C players, C hire D and before you know it, you have the politics described in this article.

It's convenient to try to squeeze his story into Steve Job's mold, but in my experience, it's the A players who tend to be the most guilty when it comes to these kinds of politics. In my company, I've worked in two departments - one full of highly intelligent folks, and the other full of mediocre ones. In the former, these kinds of politics prevailed. I recall a particular instance where one person was working on a l…

I have similar experience. People known within the company as "geniuses" are most likely to get offended when you suggest an improvement to their code. The average coders will be like "yeah, whatever".

Of course, there is a difference between being a genius, and being perceived as a genius by the managers. But sometimes there are people who are insanely good at some things (and everyone knows that) while having blind spots in other things (and get extremely sensitive about them).

Re: The Best Programming Advice I Ever Got (2012)

#236

Post by sonnyblarney »

sinisterdeath wrote: post #230
sonnyblarney wrote: post #117

Earlier quoted context omitted.

Well, many systems do IPC and often this is done over sockets. Maybe a better question is, in 2018 why don't we have much better, cleaner, simple, IPC? If the system was slow due to this, it might have been the sheer quantity of data over the IPC/Socket. Looks like they were rendering on one side (i.e. 'making the picture') and then pushing that to a different process to rasterize, i.e. 'draw it on screen' which just…

I think a common approach for IPC these days is to use named pipes. Chromium uses it and I've used it in one of my projects. You still have to deal with serialization and deserialization overhead but its usually pretty quick. https://www.chromium.org/developers/design-documents/inter-p...

Funny you should bring that up as I'm just looking into that on Node.JS - how was your experience using pipes? Any warning signs / pot holes?

Re: The Best Programming Advice I Ever Got (2012)

#237

Post by gbajson »

haxorito wrote: post #43

I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove ev…

Similar thing has happened to me. I joined a security team in a Big Bank. During the first month of my work I discovered a terrible and obvious security hole, which was there for years. My manager took me aside and explained that they can't fix it, or even start doing anything about it, because the whole team will look incompetent. I was told not do anything and reassigned to the completely different tasks far from the team. After another month, I left.

Re: The Best Programming Advice I Ever Got (2012)

#238

Post by midasz »

crimsonalucard wrote: post #128
williamdclt wrote: post #75

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsens…

It's not that simple. People have pride despite what they claim. If I rewrite an entire feature that someone did just because i think my way is better, you gotta be smart in how you think that should be done. Respect other people pride and work or dont expect them to respect yours.

Hero-culture is practically the same as blame-culture.

Re: The Best Programming Advice I Ever Got (2012)

#240

Post by hacym »

edw519 wrote: post #163

"Stay the hell out of other people's code." Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments. Bad advice if you want anything more out of your programming career. Horrible advice if you want to make a difference by sharing your gifts with those who need them. You don't get that many chances to do what OP did by jumping in and making dramatic im…

I got some good advice that I will never forget:

Always make sure you understand what is being said before you respond.

Post reply on HN