Code is only greenfield until the first commit.
false. it’s until the concrete hardens. could be quick, could be slow.
Software engineers hate code
91–100 of 235 posts
Re: Software engineers hate code
#92I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going. A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity. What I mean by this is; software either works or it doesn't. In many other professions this is not the case. So while there are many things that could be done better and mor…
My high school computer science teacher (almost 30 years ago that is) used to say: "A program that 'almost works' is like a plane that 'almost flies'".
Now I'm just trying to mentally picture what a mode of transportation that almost flies would work like via animal metaphors - would it almost fly like a chicken? or like a flying squirrel?
Re: Software engineers hate code
#93I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going. A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity. What I mean by this is; software either works or it doesn't. In many other professions this is not the case. So while there are many things that could be done better and mor…
I find it to be more nuanced. Your code has to work correctly in a bunch of scenarios. Some are very simple to see, others are nuanced corner scenarios. A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios. So, “this code works” is really a range, not a binary condition.
"Code either works or it doesn't" is more like a mindset and a pholisophy rather then truth or a fact.
In the context of this article and this thread, I was just reminded about this approach.
Hating or loving software development, other peoples code, or approach is sort of meaningless.
At the end of the day, we all get paid to build software and it is our job to make the software functional.
As long as the code works and does what it is supposed to do, thats all that matters.
Re: Software engineers hate code
#94Yes, hell is other people's code, haha. But you don't need microservices to write modular or encapsulated code.
Re: Software engineers hate code
#95> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my ca…
I think it's a culture thing in SV/VC//startup world and I think that group is very public, outspoken and sure that they speak for everyone.
Most if us aren't that but we just continue about our business developing new features and squashing bugs. I like greenfield projects but the choices and freedom they present come with a lot of non-coding and missing infrastructure.
A nice brownfield project lets me check in code, see it auto built into the dev environment and have QA feedback the next day.
Re: Software engineers hate code
#96sturgeon’s law applies. most of the time they are right to.
put another way, 90% of code is a liability, 10% of code is an asset.
i’m not sure any code ever moved from one group to the other, though good ideas may be stolen sans code.
greenfield is the only way to grow that 10%. it’s the reason startups exist.
it’s like all the failed rewrites. those engineers gained knowledge and fitness through that failure. if their current employer doesn’t retain them, that knowledge and fitness will pay dividends to the next one.
Re: Software engineers hate code
#97It's a great day when I've deleted more code than I've written!
Re: Software engineers hate code
#98Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes…
They got off easy with your analogy.
Re: Software engineers hate code
#99Earlier quoted context omitted.
Im a big advocate of rewriting code from scratch. Because on a rewrite you have a much better starting point. You have a (mostly) working solution, you understand the problem much better than on the first attempt, you have some tests and some data. Most of the time you don't rewrite it 100% from scratch, often you can copy a lot of code from the old solution. To utilize all those benefits you can't rewrite everything…
The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very e…
I'm not a usually a huge fan of buzzwords and I usually give trends time to pass before bothering with them but this is an advantage of micro services that I really like.
Re: Software engineers hate code
#100> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my ca…
Am I unusual in enjoying both?
Earlier in my career, I was stereotyped as a "maintainer", but now I've been a self-employed indie developer for years, so all of the code is mine.
Once your own code gets to be 5 years old or so, it's almost like maintaining someone else's code. It's like, why in the world did I write that before??
I guess my focus has always been on the product and the user experience, so I don't make the code itself central to my work and my identity. The code is not the product.