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

Things I Believe About Software Engineering

blog.wesleyac.com

Post reply on HN
Print view View original

211–220 of 231 posts

Re: Things I Believe About Software Engineering

#211

Post by dickjocke »

neilwilson wrote: post #64

I'm with Dijkstra "Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text spac…

Can anyone give me examples of what trivializing the correspondence between the program and the process looks like?

Re: Things I Believe About Software Engineering

#212

Post by hu3 »

dickjocke wrote: post #211
neilwilson wrote: post #64

I'm with Dijkstra "Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text spac…

Can anyone give me examples of what trivializing the correspondence between the program and the process looks like?

* Tests

* Types (Classes, Structures, ...)

* State management

* Documentation

* Formal models

Re: Things I Believe About Software Engineering

#213

Post by crimsonalucard »

oarabbus_ wrote: post #194
crimsonalucard wrote: post #177

Earlier quoted context omitted.

I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.

>One could say that in the work place, success is uncorrelated with merit. Do you truly believe this? In my career experience, success is highly correlated with merit. Sure, I have seen plenty of incompetence at high positions, and I've seen brilliant people who received little success in their careers. But overall, I'd say the correlation is very high.

You're right. What I mean is, a lot of workplace advancements happen not because of success, more-so than education.

Obviously at the very least some advancements happen due to merit and due to that, there is a correlation.

Re: Things I Believe About Software Engineering

#214

Post by crimsonalucard »

NohatCoder wrote: post #184
crimsonalucard wrote: post #177

Earlier quoted context omitted.

I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.

School and workplace is just an example of two very different merit systems. One is not inherently more right than the other.

Never said one is more right. But merit in the workplace is not quantitatively measured in any form.

Re: Things I Believe About Software Engineering

#215

Post by crimsonalucard »

thewebcount wrote: post #195
crimsonalucard wrote: post #177

Earlier quoted context omitted.

I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.

> Our schooling and educational systems are very merit based. I'm not sure where' you're based, but that's certainly not the case where I live. I once worked for a company that made grading software. I quit after 3 months because they wanted to implement features like, "Teacher wants to be able to change grade to a specific letter, even if student's scores add up to a different letter grade." (In other words, even th…

In general a student should be able to calculate his own grade given available information so that acts as a buffer to this sort of "grade editing." In general teachers won't do this due the fact that it can easily be found out.

Re: Things I Believe About Software Engineering

#216

Post by crimsonalucard »

skywhopper wrote: post #185
crimsonalucard wrote: post #174

Earlier quoted context omitted.

Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed. Have you heard of functional programming?

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relativel…

>"utmost to shorten the conceptual gap between the static program and the dynamic process"

I'm mostly referring to this part of the quote. Pure FP is basically a static program and not a dynamic process. Nothing is changing in FP, nothing is dynamic.

FP makes this gap zero. Outside of FP (the distributed system) is a different story of course.

Re: Things I Believe About Software Engineering

#217

Post by karmakaze »

bartread wrote: post #186
karmakaze wrote: post #136

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Pair programming can easily double that and the low productivity periods are not nearly as low.

> Pair programming can easily double that and the low productivity periods are not nearly as low. Pfft. Prove it. People are very different and work best in different ways. I don't mind pair programming for specific reasons but as a the "normal" way of working? You can keep it. Pair programming performed relentlessly selects for certain personality types. I, for example, didn't get into programming because I wanted t…

All good points and I was of the same opinion before I underwent almost 2 years of mostly pairing. My takeaways:

People are different. The core bunch came from Pivotal which performed pair-programming interviews so were self selected. That accounted for about half the engineering staff so the other half didn't undergo this process. I myself have always been a solo developer so pairing was very unnatural at first and I didn't pair well with everyone. We rotated pairs every week (sometimes two) so that wasn't a big problem.

There are times when solitary deep thought is useful and breaks for that activity could be taken at will while the other pair works on maintenance tasks etc. Most of the time the work isn't of this type and more often less complex requiring light whiteboarding or on-screen prototyping which both work well when pairing.

The style of code that comes out of pairing tends to be more plain than when working solo. There is incremental progress in both implementations and design refinements when pairing. When working solo there tends to be grander designs with a moment where it all comes together or not. I enjoy the latter but find the former higher by average throughput. Pairing tends to eliminate more of the 'might need soon' or 'will need in the future anyway' implementations.

After pairing with someone a few times, verbal communication becomes very terse and fluid. An unexpected benefit was the ability to immediately resume context after interruptions or breaks.

The biggest advantage of pair-programming that doesn't get mentioned much is the organic spread of good practices and conventions. With approximately 20 devs it's not really worth writing and maintaining standards documentation and conventions for handing new cases that keep appearing. With rotating pairs this discovery of what works well and normalization upon it is natural. Minor tips and tricks aside from the source code can also be invaluable power-ups when learned by others.

Pair programming isn't about maximizing 'your own productivity' it's about maximizing the productivity, quality, and consistency across all dev teams.

Within that period we also tried full-stack dev pairing. This was much more challenging and didn't work nearly as well. We didn't stick with it long enough to know if it could become more beneficial because basically people self-selected into front or back-end development and liked it that way.

These are my findings from being both a solo and pair-programming developer. If you're curious and have an opportunity I highly recommend trying to stick with it for a while and see what your findings are.

Re: Things I Believe About Software Engineering

#218

Post by johntran »

thewebcount wrote: post #195
crimsonalucard wrote: post #177

Earlier quoted context omitted.

I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.

> Our schooling and educational systems are very merit based. I'm not sure where' you're based, but that's certainly not the case where I live. I once worked for a company that made grading software. I quit after 3 months because they wanted to implement features like, "Teacher wants to be able to change grade to a specific letter, even if student's scores add up to a different letter grade." (In other words, even th…

I took Calculus AB in high school and the teacher was notorious for giving students D's and F's because of his teaching style was poor and the exams were difficult. The only saving grace from that class was that you would be given a C if you scored a 4+ on the AP exam.

He still kept his job because majority of the class got 4+'s on those exams, despite at least 1/3 of his class getting D's and F's.

I wouldn't generalize editing letter grades as a way of "cheating the system". There's usually good intentions in every act.

Re: Things I Believe About Software Engineering

#219

Post by l0b0 »

> Being aligned with teammates on what you're building is more important than building the right thing.

It's important to define the terms here. Does "important" mean important to you or the company? I could understand the former, but how are you ever going to build the "right thing" if you can't agree as a team what you're building?

Re: Things I Believe About Software Engineering

#220

Post by karmakaze »

andruby wrote: post #58

> Being aligned with teammates on what you're building is more important than building the right thing. I would write this as: Building the right thing wrong is more important than building the wrong thing right. And I firmly believe that agreeing on _what_ you are builing is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.

> Building the right thing wrong is more important than building the wrong thing right.

I entirely agree with this, but don't think that's what the original point was getting at.

> And I firmly believe that agreeing on _what_ you are building is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.

This seems like it should be true. In practice, I've found that the _how_ is the part that gets embedded in the wet-ware of people/companies and is the hardest to change.

Given an application written in a language with some framework, some datastore, deployed to some cloud, it's actually exceedingly easy to make another that follows that pattern and does a completely different business function. Much more challenging would be to change those parts of an application and keep it doing the same thing.

Post reply on HN