Any day that has a negative LOC count is a good day :)
This usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is now boilerplate.
If I can also add a feature with a negative net LOC count, it is a gold-star day :)
That being said, sometimes just dumping a pile of code that passes tests, but is large (bloated), unwieldy and redundant is the right move. It give me something to refactor and abstract, and gets things done.
I’m with you. The most rewarding thing about diving into a large codebase is that you have many opportunities to refactor while you add features. At my current job I add only marginally more code than I delete. Feels good. :)
Sure -- as long as there are tests and some semblance of order. Trying to add new features to an untested ball of mud is just about the worst possible thing one can inflict on a poor programmer.
I consider the big-ugly code to be a part of the learning curve - it exposes "concrete" problems of implementation, and once built, you nurse it through a few rounds of changes before a major refactor or redesign to sweep up all the new concerns.
The main problem of this strategy is with other people - as soon as you have a whole team pounding away at the same piece of code, the incremental changes obscure a high-level revised view of the problem, being distributed across several minds. Descent into a ball of mud becomes the status quo.
On the other hand, optimizing the source text prematurely(either via code golf or Big Architecture) is even worse since it's not even built on a stable foundation of intention, then, but on guesses or convenient hacks.
Code you never write never breaks. It has astonished me how much code people can crank out. It does not astonish me that they spend most of their time maintaining things they've written.
Because I've been around the block enough to know that if you think code not written doesn't do anything, then code you write MUST do something. The reality is most code does nothing (other than push data around), and the actual code that really drives the value is primarily an innovation that lives in one component of the code-base. All other code is expendable and most of it is putting a pretty face on the raw functionality or adding usability, options, etc.
All code needs to be taken into account holistically. Sure, you added some code that sends alerts. It actually does something. Well, do your customers care? Are they willing to upgrade to the latest version? Does that piece of code actually change the business strategy, market penetration, or mindshare? 90% of the time code is checking boxes against competitors or providing some benefit that does not have a huge impact to the bottom line of the business. Again, MOST code.
So I make assumptions based directly of years of experience. Most of the code anyone writes barely does anything. The amount of code that is written compared to the amount of code that actually makes meaningful changes to the business or the world at large is probably 50:1.
Honestly, as a data point... you were wrong. I was just being a smart ass.
If I had any thought in mind besides just to be a contrarian it was, to quote Voltaire, "A witty saying proves nothing.".
I've been around the block a bit too and I know that these articles on HN and the one-line summations of "write more code", "write less code", "write purple code", "Code you don't write doesn't have bugs", etc. don't really mean anything more than my stupid "... but doesn't do anything either. :P".
It's like throwing people random tools out of a toolbox. "When you do carpentry, use a chisel", "For building houses, a hammer is what you need", etc.
If the carpenters you're throwing a chisel to don't know how to properly use a chisel, then just throwing one at them isn't helpful. If they already know how to use a chisel, then you're not helping them either.
Maybe you were just trying to give them a clever-sounding quote with an obvious rejoinder to throw out on HN and thus promote a little discussion? In that case, I guess it worked well enough. :)
Code is a by-product of software development in the same sense as a blueprint is a by-product of engineering. Teaching a programming language doesn't turn someone into a software developer just as teaching technical drawing doesn't turn someone into an engineer.
I think you're being a bit free with the metaphors here.
A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?
Yeah, I'm playing with metaphors here. The point I want to get across is the code itself is just a means to an end. Just the code is often not a deliverable, unless you make money from software patents. Google doesn't make money because they sell a lot of code. Facebook doesn't get investment because they wrote a lot of code. That doesn't mean their code isn't valuable - it is. But it's the actual computation (e.g. execution of this codebase) that has real value. Get it?
That attitude leads to devaluing software, followed by bugs, a legacy codebase and not being able to extend your software when your competitors catch up. Programs and the problems that they solve are intertwined. You can't easily separate them - which is why your metaphor doesn't work.
I find as a general rule, the more that my application tries to abstract and protect the user from the "technical" nature of the platform the more code I have to write.
For example I produced a CMS that was intended to be used by content writers who were not technical.
However as the complexity of the website increased (more dynamic content on pages etc) I had to write a lot of code because there were a lot of exceptional cases "I want this side bar to appear on all of these types of pages apart from these 3 because of condition X and this other one because of condition Y". This means that my code ends up being an enormous pile of if statements with a huge number of database flags at the backend and checkboxes on the front end.
In the end it proved more effort efficient to produce a simple tag language for the front end and expose that to the designers and content writers, this took a lot of complexity out of the back end which could then concentrate on providing the primitives for the tag language.
You do move some complexity to the front end here for sure, but people are often better at specifying what it is they mean if they can actually generate and tweak it to some extent themselves and show the result rather than trying to explain everything in an email.
Another great example of this is Unix command line utilities , the basic interface for many of these has remained relatively unchanged since the 80s whereas GUI applications seem to be continuously redesigned.
Part of the zen of Python is "Flat is better than nested". Until recently, I always thought of this at a code block/function level. Recently I realized that this is also important when modularizing and adding layers of abstraction. The more layers of abstraction (from foo.bar.baz import Baz) you add, the more code you write and have to "keep in your mind". This presentation by Jack Diederich at PyCon 2012 really opened my eyes to the potential problems of adding layers of abstraction via modules and classes: http://pyvideo.org/video/880/stop-writing-classes
Interesting you say that; I would argue (and have) the exact opposite. Good abstractions, by their very nature, reduce the amount of moving parts you have to keep in your head at any one time. When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
> When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when reading at a later date. It has become tiresome and now I consciously start at the other end, making the simplest thing that could work. Layers of abstraction then come naturally as needed.
This is the best approach , but it is best combined with fairly comprehensive re factoring otherwise you end up in a situation I have been in a few times where you have new code that runs with a nice abstraction and old code that works with less abstraction.
At that point you can introduce bugs because somebody modifies the old code in a way which would not be allowed under the new abstraction and then the new code ends up reading data produced by the old code leading to a cascade of failure.
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code because their idea of re-use is copy-pasting the same bit of code they found online into every place they think it will fit and changing it around in various ways in different places so it becomes very hard to abstract later. They also like to stick with the same set of now deprecated APIs they learned 10+ years ago which means that it becomes hard to take advantage of newer libraries which were not built with these in mind, meaning that you will do a lot of wheel re-invention or shimming. They tend to think of economizing on effort and brain usage right now rather than economizing on technical debt in the long run.
There is also sometimes a trade off between saving time for the programmer and saving time for others. For example a manager might want a feature that saves them 10 minutes of time once a month when they want to produce a particular report but may cost programmers several hours a month just keeping this feature up to date. In this case it comes down to who's time is more valuable.
The best way to explain this to people is in terms of "tax" (since everyone hates that). I was once asked by a management type "I used to get all my changes turned around same day, now I seem to wait weeks or even months. What's going on?"
Of course the simple answer to this question is that a year ago the program was about 10Kloc , now it's more like 200Kloc. It's also much more "mission critical" than it was. A year ago the program was small enough that I could easily imagine all the consequences of making a change in my brain so I could do basic testing and push to production, now a small change can have many consequences so it has to be thoroughly tested first.
So the analogy to make would be the government building infrastructure for say the road network. The upfront cost of building is $x , but when doing that you commit to $y spending per year (in terms of cost+time) to keeping that going.
Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical.
Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing.
It's also partly a political issue, I've spent months adding features to codebases that I know for a fact are not required because somebody with enough influence simply insists that it will be important. There is only a certain level of argument you can get into before you get to "do as you are told", that level will of course depend on many non-technical factors.
Another interesting point is that I find sometimes people will request feature X because they are perusing a line of though that will eventually lead them to conclude that they actually need feature Y. In many cases feature Y may be easier to implement (or maintain) than feature X but they simply haven't reasoned that far ahead yet so will insist that they want feature X now but acknowledge that they may change to feature Y a few months down the line.
"I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code (...)"
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard.
"Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing."
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
In fact, I can only feel sorry for any business which depends fundamentally on software and doesn't have a developer as the main stakeholder.
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard.
I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too.
If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all.
If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run.
After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers.
I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers.
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing.
It's an interesting point about automation and how much stake a developer should have in a business.
Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere.
Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made?
This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?
You don't have to love the ride to enjoy the trip. Programming is just a means to an end. We love the end, not the mean. He's not talking about worrying "how soon can I go home today". You do have a powerful motivator, which is the awesome software you're gonna build. You wanna write code because you wanna see your own thing built and working. Not because you love writing text on the editor.
If I could build great software without writing code I would. Unfortunately we're not there yet. As you said it yourself, most businesses now depend fundamentally on software. So being inside and working to make your code base as good and maintainable as possible, and understand those processes is important. So we do care about writing good software. But not because we love writing code, but because we hate that.
Right, but that's not an especially incitefull distinction to make. I imagine there are very few programmers around who
love programming because it means they get to type lots of characters into a text editor in the same way that nobody enjoys sex because it means they get to exercise their hips.
In fact this is probably a big motivator in the number of open source libraries available now, they were developed by somebody who wanted to achieve thing X but they needed to create byproduct Y in order to do that.
So it makes sense to share by byproduct Y with the people who need to make thing Z.
Not to be a pedant, but I think you meant "yak-shaving"(1) not "bike-shedding"(2). Shaving yaks is fun. A little too much fun. Bike-shedding is always misery.
Thanks, but I really meant bikeshedding - that is, people who "love" coding tend to also "love" wasting time in the details instead of focusing in the big picture.
For what it's worth, I don't agree with you at all. It's like you're saying that the best chefs are those who hate cooking the most. It's a ridiculous notion that betrays a misunderstanding of the relationship between what we do and what is produced by it.
The irony is that the parallel you made with chefs just proves my point. E.g.: chefs care about delicious dishes, great presentations, evoking emotions, not keeping customers waiting, etc. On the other hand, go ask a chef if he loves chopping vegetables ;) In fact, they couldn't care less about this kind of minutae and develop techniques to do it fast and not waste time. Analogously, coding is the chopping of software development.
Thanks for posting that. I thought I was the only one around here to thought like that :) I write code every day, but I hate programming. What I really enjoy is building things and it just so happens that in software you have to write code to build things. Programming is a means and not an end.
Way too many people think programming is the end. If I could build awesome stuff without having to write code, I would. Unfortunately, I still have to write code today. That's why my current project is about writing lots of code now, so others don't have to write code later :) As the article points out, that's where current tools are heading. Hopefully in the future we'll have better abstraction so everyone needs to code less to get more done.
To be a good developer you have to know what you're doing. That is, to know when it's a good idea to write more code, and to know when it's an even better idea to challenge the rationale for writing it in the first place.
I don't think the assertion that raw, passionate emotion (ie. hate) drives a good developer is an ideal, or a correct one.
Not only good programmers hate programming, they also try to make it suck less. That's when they come up with new languages, frameworks and abstractions ;)
the job of a designer is it, to let things look beautiful in different ways: in the way it looks, it feels, how to use it and so on.
i wouldn't say that i'm only a software engineer, but also a software designer.
code == ui
code has to look beautiful, it should feel good to work with, easy to use, etc.
"The cheapest, fastest, and most reliable components are those that aren't there." -- Gordon Bell
Just to clarify. I think what he means by that statement is that, we assume that components not yet built would be cheaper, faster and more reliable than they would be in reality. Which is almost always true.
[EDIT: Just realized, it's true the other way around too, if you eliminate the need for a component, it becomes the cheapest, fastest and most reliable component.]
If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. -- Dijkstra
(I got this from akkartik but can't remember where.)
My principles with software development are simple. Code should be clean, beautiful and do exactly what you want it to do.
I agree with the advice doled out by the author about spending more time on thinking than actual programming. This is something most good developers eventually learn as they get more experienced. To immediately dive in and implement as you find issues would cost you more time in the longer run.
Also, putting it on paper always helps. Especially when you're dealing with large software or changes to complex algorithms. It helps to visualize it on a more permanent medium than the brains fickle whiteboard.
Ultimately, unless you work on the software like you have a stake in it, you wouldn't spend enough mind on it to do the continuous re-factoring and improvements it takes to make great software. This is especially true in a commercial environment where deadlines and releases and user visible improvements are the focus of the management. It is upto you to care about what happens under the hood and eventually you will wish you had.
I think this applies on every scale. Not just writing more elegant code but also just writing code in smaller units and having a prejudice against large methods/classes/components. I've noticed a lot of devs have a mental block about things like one-line methods or extracting a single conditional test into a method and other trchniques that really do help make your code clearer.
The more experienced I get the more I come to view big code as an anti-pattern / code smell.
"The problem is largely philosophical: as software developers we're trained to think in terms of rigid systems of objects, design patterns and re-usable code. You might set out with the great idea to build a system of classes with clearly defined interfaces that inherit from one another when specialized behavior is needed. You might model all this in Lua using any number of class and inheritance patterns to try and enforce your vision. But, if you're perceptive, you'll soon start to suspect that all of the work you're doing to build an architecture really doesn't add much practical value. You may find yourself in the situation of having spent a lot of time defining a traditional OOP-style inheritance hierarchy and a big pile of fancy data structures only to realize you've created nothing more than an especially convoluted way of initializing tables.
Fortunately, there's an easy solution: don't do it. "
If you find a way to avoid writing ASCII codes, or avoid it most of the time, then you aren't programming. And therefore, you are no longer a programmer.
Arranging, configuring and connecting components/widgets with GUIs is a very powerful way to solve all sorts of problems in many application domains. Unfortunately, the more powerful a system like that is, the less attractive it is for 'software developers' because it means they mostly aren't writing code, but rather are dragging around widgets.
I'm building a system like that anyway, for my own personal sanity. It is definitely a tool for advanced software developers to create, publish and configure widgets, not just for users or designers, although its also specifically for users and designers as well. I expect that most software developers will not appreciate it because it will make it too easy to build powerful applications without writing code.
The biggest thing holding back software engineering right now is source code.
The problem is that the definition of programming and software development is outdated. Programmers write colorful ASCII codes.
there is no universal truth other than balance and careful judgement. Say "write less code" to the wrong person, and they will go off and create six months of meetings where they decide what they should decide what they should decide to decide to do. Analysis paralysis will creep in and kill you.
53 comments
[ 3.3 ms ] story [ 94.1 ms ] threadThis usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is now boilerplate.
If I can also add a feature with a negative net LOC count, it is a gold-star day :)
That being said, sometimes just dumping a pile of code that passes tests, but is large (bloated), unwieldy and redundant is the right move. It give me something to refactor and abstract, and gets things done.
It's all about balance.
The main problem of this strategy is with other people - as soon as you have a whole team pounding away at the same piece of code, the incremental changes obscure a high-level revised view of the problem, being distributed across several minds. Descent into a ball of mud becomes the status quo.
On the other hand, optimizing the source text prematurely(either via code golf or Big Architecture) is even worse since it's not even built on a stable foundation of intention, then, but on guesses or convenient hacks.
... but doesn't do anything either. :P
All code needs to be taken into account holistically. Sure, you added some code that sends alerts. It actually does something. Well, do your customers care? Are they willing to upgrade to the latest version? Does that piece of code actually change the business strategy, market penetration, or mindshare? 90% of the time code is checking boxes against competitors or providing some benefit that does not have a huge impact to the bottom line of the business. Again, MOST code.
So I make assumptions based directly of years of experience. Most of the code anyone writes barely does anything. The amount of code that is written compared to the amount of code that actually makes meaningful changes to the business or the world at large is probably 50:1.
If I had any thought in mind besides just to be a contrarian it was, to quote Voltaire, "A witty saying proves nothing.".
I've been around the block a bit too and I know that these articles on HN and the one-line summations of "write more code", "write less code", "write purple code", "Code you don't write doesn't have bugs", etc. don't really mean anything more than my stupid "... but doesn't do anything either. :P".
It's like throwing people random tools out of a toolbox. "When you do carpentry, use a chisel", "For building houses, a hammer is what you need", etc.
If the carpenters you're throwing a chisel to don't know how to properly use a chisel, then just throwing one at them isn't helpful. If they already know how to use a chisel, then you're not helping them either.
Maybe you were just trying to give them a clever-sounding quote with an obvious rejoinder to throw out on HN and thus promote a little discussion? In that case, I guess it worked well enough. :)
A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?
For example I produced a CMS that was intended to be used by content writers who were not technical. However as the complexity of the website increased (more dynamic content on pages etc) I had to write a lot of code because there were a lot of exceptional cases "I want this side bar to appear on all of these types of pages apart from these 3 because of condition X and this other one because of condition Y". This means that my code ends up being an enormous pile of if statements with a huge number of database flags at the backend and checkboxes on the front end.
In the end it proved more effort efficient to produce a simple tag language for the front end and expose that to the designers and content writers, this took a lot of complexity out of the back end which could then concentrate on providing the primitives for the tag language.
You do move some complexity to the front end here for sure, but people are often better at specifying what it is they mean if they can actually generate and tweak it to some extent themselves and show the result rather than trying to explain everything in an email.
Another great example of this is Unix command line utilities , the basic interface for many of these has remained relatively unchanged since the 80s whereas GUI applications seem to be continuously redesigned.
This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when reading at a later date. It has become tiresome and now I consciously start at the other end, making the simplest thing that could work. Layers of abstraction then come naturally as needed.
At that point you can introduce bugs because somebody modifies the old code in a way which would not be allowed under the new abstraction and then the new code ends up reading data produced by the old code leading to a cascade of failure.
The phrase you're looking for is "Conservation of complexity" :)
There is also sometimes a trade off between saving time for the programmer and saving time for others. For example a manager might want a feature that saves them 10 minutes of time once a month when they want to produce a particular report but may cost programmers several hours a month just keeping this feature up to date. In this case it comes down to who's time is more valuable.
The best way to explain this to people is in terms of "tax" (since everyone hates that). I was once asked by a management type "I used to get all my changes turned around same day, now I seem to wait weeks or even months. What's going on?"
Of course the simple answer to this question is that a year ago the program was about 10Kloc , now it's more like 200Kloc. It's also much more "mission critical" than it was. A year ago the program was small enough that I could easily imagine all the consequences of making a change in my brain so I could do basic testing and push to production, now a small change can have many consequences so it has to be thoroughly tested first.
So the analogy to make would be the government building infrastructure for say the road network. The upfront cost of building is $x , but when doing that you commit to $y spending per year (in terms of cost+time) to keeping that going.
Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing.
It's also partly a political issue, I've spent months adding features to codebases that I know for a fact are not required because somebody with enough influence simply insists that it will be important. There is only a certain level of argument you can get into before you get to "do as you are told", that level will of course depend on many non-technical factors.
Another interesting point is that I find sometimes people will request feature X because they are perusing a line of though that will eventually lead them to conclude that they actually need feature Y. In many cases feature Y may be easier to implement (or maintain) than feature X but they simply haven't reasoned that far ahead yet so will insist that they want feature X now but acknowledge that they may change to feature Y a few months down the line.
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard.
"Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly it assumes that the developer understands every aspect of the business well enough to evaluate this, in which case they really may as well just put the developer in charge of the whole thing."
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
In fact, I can only feel sorry for any business which depends fundamentally on software and doesn't have a developer as the main stakeholder.
I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too.
If you hate your job then your main motivator is "how soon can I go home today?" or "how little brain power can I invest in this?" you will not be interested in the LOC count of the project at all. If you enjoy programming then you are more likely to want to expend more effort thinking about how you could write the same thing using less/more maintainable code. There are of course programmers who will over architect solutions but this is usually because they believe that they are creating a structure that will keep LOC count lower over the long run.
After all code saving things like MVC/ORM frameworks were originally used by the early adopter more enthusiastic programmers.
I would say it's better to hate large bloated codebases, but I can't think there are many programmers who create these on purpose, it is usually a by product of flawed assumptions made in earlier stages or less skilled programmers.
If he doesn't understand the aspects of the business and doesn't have any stake on the final product he's not a developer, he's just a programmer doing repetitive work at a software factory - "code monkey" on jargon - and is not in a position to provide the kind of disruptive, ten-fold improvement software is able to produce.
Again this is sort of semantics, most companies will advertise positions that are repetitive "factory" jobs as "developer" positions. In fact some of the better programmers I know refer to themselves as "code monkeys" so I guess this is really a cultural thing.
It's an interesting point about automation and how much stake a developer should have in a business. Most businesses now depend fundamentally on software in one way or another, for a glaring example of this see the UK banks that have had to cease pretty close all activity for the best part of a week because of a software problem. Also pretty much also businesses above a certain size have some custom code running somewhere.
Does this mean that all businesses should have a developer present at board level? Also should that board level person simply be someone with development experience or should they be involved in the day to day code production so that they can understand all of the decisions made?
This also ties into the debate about who should learn to program, for example do you get that experience at board level by teaching executives to write programs or instead do you promote programmers to board level and teach them about "business stuff"?
If I could build great software without writing code I would. Unfortunately we're not there yet. As you said it yourself, most businesses now depend fundamentally on software. So being inside and working to make your code base as good and maintainable as possible, and understand those processes is important. So we do care about writing good software. But not because we love writing code, but because we hate that.
In fact this is probably a big motivator in the number of open source libraries available now, they were developed by somebody who wanted to achieve thing X but they needed to create byproduct Y in order to do that.
So it makes sense to share by byproduct Y with the people who need to make thing Z.
(1) http://en.wiktionary.org/wiki/yak_shaving*
(2) http://en.wiktionary.org/wiki/bikeshedding*
Way too many people think programming is the end. If I could build awesome stuff without having to write code, I would. Unfortunately, I still have to write code today. That's why my current project is about writing lots of code now, so others don't have to write code later :) As the article points out, that's where current tools are heading. Hopefully in the future we'll have better abstraction so everyone needs to code less to get more done.
I have not seen a programmer who hated programming and wrote good code.
I don't think the assertion that raw, passionate emotion (ie. hate) drives a good developer is an ideal, or a correct one.
To be a good programmer, among other things, you need to love good code, and hate bad code.
Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.
maybe this is all about the zen of coding.
"One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
"Deleted code is debugged code." — Jeff Sickel
And probably my favorite (because this doesn't apply only to lines of code):
"The cheapest, fastest, and most reliable components are those that aren't there." -- Gordon Bell
Just to clarify. I think what he means by that statement is that, we assume that components not yet built would be cheaper, faster and more reliable than they would be in reality. Which is almost always true.
[EDIT: Just realized, it's true the other way around too, if you eliminate the need for a component, it becomes the cheapest, fastest and most reliable component.]
(I got this from akkartik but can't remember where.)
I agree with the advice doled out by the author about spending more time on thinking than actual programming. This is something most good developers eventually learn as they get more experienced. To immediately dive in and implement as you find issues would cost you more time in the longer run.
Also, putting it on paper always helps. Especially when you're dealing with large software or changes to complex algorithms. It helps to visualize it on a more permanent medium than the brains fickle whiteboard.
Ultimately, unless you work on the software like you have a stake in it, you wouldn't spend enough mind on it to do the continuous re-factoring and improvements it takes to make great software. This is especially true in a commercial environment where deadlines and releases and user visible improvements are the focus of the management. It is upto you to care about what happens under the hood and eventually you will wish you had.
The more experienced I get the more I come to view big code as an anti-pattern / code smell.
"The problem is largely philosophical: as software developers we're trained to think in terms of rigid systems of objects, design patterns and re-usable code. You might set out with the great idea to build a system of classes with clearly defined interfaces that inherit from one another when specialized behavior is needed. You might model all this in Lua using any number of class and inheritance patterns to try and enforce your vision. But, if you're perceptive, you'll soon start to suspect that all of the work you're doing to build an architecture really doesn't add much practical value. You may find yourself in the situation of having spent a lot of time defining a traditional OOP-style inheritance hierarchy and a big pile of fancy data structures only to realize you've created nothing more than an especially convoluted way of initializing tables.
Fortunately, there's an easy solution: don't do it. "
From : http://getmoai.com/wiki/index.php?title=Structuring_Your_Moa...
I think that quote, or something like it, is from the 80's.
I've found this is the hardest thing for non tech business partners to understand, because most of the time, it appears as if you are doing nothing.
Arranging, configuring and connecting components/widgets with GUIs is a very powerful way to solve all sorts of problems in many application domains. Unfortunately, the more powerful a system like that is, the less attractive it is for 'software developers' because it means they mostly aren't writing code, but rather are dragging around widgets.
I'm building a system like that anyway, for my own personal sanity. It is definitely a tool for advanced software developers to create, publish and configure widgets, not just for users or designers, although its also specifically for users and designers as well. I expect that most software developers will not appreciate it because it will make it too easy to build powerful applications without writing code.
The biggest thing holding back software engineering right now is source code.
The problem is that the definition of programming and software development is outdated. Programmers write colorful ASCII codes.
https://github.com/ithkuil/cureblog
https://vimeo.com/43784316
this sucks dick
http://www.folklore.org/StoryView.py?project=Macintosh&s...