Things I’ve learned in my 20 years as a software engineer • Hacker News Board

Re: Things I’ve learned in my 20 years as a software engineer

#211

Post by lincpa » Fri, Oct 08, 2021, 2:11 PM UTC

You might like a programming methodology based on elementary school mathematical models (take Clojure as example)----The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model.

Based on the simplest and most vivid mathematical model is its biggest advantage.

Its mathematical prototype is the "water in/out of a pool" problem in elementary school mathematics. When we increase the number of pools and water pipes, the combination of different types of liquids, the time and speed of input and output, and other factors in this mathematical problem. It forms a warehouse/workshop model in the form of a dynamic tree Gantt chart. It should be the IT architecture with the simplest and most vivid mathematical prototype.

It is an epoch-making theoretical achievement in the IT field, it surpasses the "von Neumann architecture", unifies the IT software and hardware theory, and raises it from the manual workshop production theory level to the modern manufacturing industry production theory Level. Although the Apple M1 chip has not yet fully realized its theory, Apple M1 chip has become the fastest chip in the world.

It has a wide range of applications, from SOC to supercomputer, from software to hardware, from stand-alone to network, from application layer to system layer, from single thread to distributed, from general programming to explainable AI, from manufacturing industry to IT industry.

The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model:

https://github.com/linpengcheng/PurefunctionPipelineDataflow

Re: Things I’ve learned in my 20 years as a software engineer

#212

Post by dgb23 » Fri, Oct 08, 2021, 2:12 PM UTC

begueradj wrote: post #66

"If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system" That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document

You are conflating process with design. You can have an iterative process and still take time to think, design and specify things.

Re: Things I’ve learned in my 20 years as a software engineer

#213

Post by sporedro » Fri, Oct 08, 2021, 2:12 PM UTC

I feel like once you’ve worked on a few projects the desire to “reinvent” the wheel is quickly destroyed. The main thing they never teach in school and you really can’t understand until your doing it is maintenance.

Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.

Re: Things I’ve learned in my 20 years as a software engineer

#214

Post by vnorilo » Fri, Oct 08, 2021, 2:12 PM UTC

boffinAudio wrote: post #7

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

I think software is human expression. It can be a social good or a business driver. But it does not have to be. It can have no users, no IO or never run on a computer and still encode deep meaning.

Does it need to be social to be useful? That is a value system.

Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.

Re: Things I’ve learned in my 20 years as a software engineer

#215

Post by bogwog » Fri, Oct 08, 2021, 2:14 PM UTC

Aaargh20318 wrote: post #172

itsibitzi wrote: post #48

Earlier quoted context omitted.

Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience. The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked. I feel this "10x programmers are…

> The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked. Not just avoid pitfalls, being able to put together a good architecture is a huge factor as well. The effect is cumulative. If you have a good design to begin with, everything becomes easier with less risk of bugs. The result is that implementing new, or changing existing functio…

> (s)he will probably write less code than the 1x developer.

Or better yet, remove code.

Re: Things I’ve learned in my 20 years as a software engineer

#216

Post by JackFr » Fri, Oct 08, 2021, 2:15 PM UTC

vishnugupta wrote: post #23

> 13. Your data is the most important part of your system +1. Most (including me) internalise, if at all, this lesson the hard way through trial and error. I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data. I expected Domain Driven Design (DDD) would address this but it doesn't.

Thirty years ago at my first job, a senior dev told me "2% of what we do is interesting. 98% is sort, select, sum."

(I think then that was more or less true, but the numbers in the industry as a whole have gotten a lot better in the past 30 years. And I've gotten better jobs.)

Re: Things I’ve learned in my 20 years as a software engineer

#217

Post by darthvoldemort » Fri, Oct 08, 2021, 2:16 PM UTC

chaps wrote: post #184

boffinAudio wrote: post #7

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact t…

If you're volunteering, why shouldn't you work on projects that you find interesting? I don't understand the point of view of the older dev.

Re: Things I’ve learned in my 20 years as a software engineer

#218

Post by the_only_law » Fri, Oct 08, 2021, 2:17 PM UTC

> “How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often.

My problem is I’ve heard of it, probably even know a bit about it but never used or worked with it. Meanwhile it seems like everyone around me is both an insane domain expert in their own thing while also a pretty damn good generalist having worked across everything.

Re: Things I’ve learned in my 20 years as a software engineer

#219

Post by fesc » Fri, Oct 08, 2021, 2:18 PM UTC

vbezhenar wrote: post #54

sunnyday1337 wrote: post #18

I have seen many similar posts what people have learned but not once have I seen: "Don't assume anything". So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.

That's a useless advice IMO. How can you not assuming anything. I assume that my CPU works, for example. You can't write useful programs without many assumptions. Imagine program that does not assume that CPU works and reruns every algorithm few times with few different code versions to verify that outputs match. It might make sense for moon mission, but definitely not for another CRUD app. I don't have 20 years of e…

I completely agree with your second paragraph but the last sentence seems like you don't know what people mean when they say they hate NullPointerExceptions.

They don't mean that you just silently ignore the null value, they mean that they would prefer to use a language that has proper optional types.

Re: Things I’ve learned in my 20 years as a software engineer

#220

Post by pjc50 » Fri, Oct 08, 2021, 2:18 PM UTC

NineStarPoint wrote: post #185

itsibitzi wrote: post #48

Earlier quoted context omitted.

Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience. The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked. I feel this "10x programmers are…

Realistically, I’ve always found it a weird sentiment more because issues caused by software developers are not of the “this person is 1/10 as productive as this other person” type. A bad developer isn’t a low positive effect on a project, but an active negative effect. As such, you can put literally any Y for a (Y)X programmer, since the scale of how inefficient a programmer can be goes up to infinite. I think the p…

More people should be aware of Comrade Stakhanov, the "10x miner": https://en.wikipedia.org/wiki/Alexey_Stakhanov

> In 1988, the Soviet newspaper Komsomolskaya Pravda claimed that the widely cited achievements of Stakhanov were puffery. The paper insisted that Stakhanov had used a number of helpers on support works, while the throughout was tallied for him alone. Still, according to the newspaper, Stakhanov's approach had eventually led to increased productivity by means of a better work organization, including specialization and task sequencing

Exactly the same discussion, except there it was tonnes of coal which can be easily and unambiguously measured. But they can't be easily attributed. How much of his work was really that of his team? And how much of it was simply inflation by his managers for propaganda purposes? And how much of it was, underneath all the propaganda, real process improvements?