... continued ...

Coding is a creative process. It is fun. It is satisfying, rewarding, and empowering. Coding is about solving problems and there are a multitude of proper solutions for any single problem. Probably no solution is really better or worse than any other. As long as it solves the problem efficiently, who cares? Start with a bunch of code puke which solves your problem. Then go over it again and again, refining it, touching it up, perfecting it. It's never really finished. Like any other art form (e.g. painting, sculpting, writing, etc.), coding is an iterative process without any real ending. You just end up deciding its good enough and its done. Think like water and code like the wind.

Some code has soul and some doesn't. You can tell when you run across a truly fine crafted piece of software that has some soul in it. It is unique and is a joy to use. From the UI to more technical aspects, it solves its problems in its own special way. X-plore File Manager by Lonely Cat Games on Android is (I feel) an example of this. I don't know anything about it other than I use it every once in awhile, but I can almost feel the care and attention to detail that went into building it. It wasn't just pressed out of some framework's factory and slightly modified to adapt to a specific purpose. It stands on it's own and has integrity. It's got soul.

TL;DR: Coding is an art form. Structure limits freedom. Some structure can be helpful. Think like water and code like the wind. Code can have soul.

Same here. I have been developing for about 35 years. Have written code in almost all popular languages and have followed MS in all their development iterations up to WPF. I loved OOP and I loved Design Patterns. It totally satisfied my coding OCD. The problem is that these development paradigms (OOP, etc) attempt to add increasing amounts of definition and structure to something which is essentially an art form (i.e. coding is an art form).

I am not saying that structure is bad. I am saying that there is a diminishing returns on this structure. On the one hand, you have something like assembler which has the least amount of structure. In assembler, anything is possible. Code is data, data is code, and you can jump execution to anywhere you want to. One the other end, you have something like WPF which has a high amount of structure. Yes, you can have a beautiful and highly interactive datagrid which bound to a SQL server in like 3 lines of code, but trying to do anything outside of what the WPF designers originally envisioned is nearly impossible.

Where structure comes in real handy is where technologies interact. An excellent example of this is the OSI Model which defines discrete areas of functionality within a networking system. These definitions/distinctions are pretty much self-evident if you think about it and they describe a very good (the best?) way to develop networking systems. In this case, structure enables development rather than retarding it. Another good example of structure is the concept of Interfaces. An Interface is all structure and no functionality. Interfaces allow you to define how two (or more) independent pieces of code will interact. Again, this enables development.

To come back to the article you linked to ... I like this guy's "compression-oriented programming" approach. I think it shows the proper way to introduce structure into the coding process. Design Patterns are a signpost for where you want to go rather than a blueprint of how to build it. Design Patterns are what happens after you go through the process that is described in the article. I think this is probably the message/intent behind Fowler's book Refactoring to Patterns. On the other end of the spectrum, WPF is what happens when you take Design Patterns too literally and start your coding from that point of view. Also, structure begets more structure. To code with WPF you have to use additional structure in the form of one or more toolkits and frameworks to really get anything done.

Same here. I have been developing for about 35 years. Have written code in almost all popular languages and have followed MS in all their development iterations up to WPF. I loved OOP and I loved Design Patterns. It totally satisfied my coding OCD. The problem is that these development paradigms (OOP, etc) attempt to add increasing amounts of definition and structure to something which is essentially an art form (i.e. coding is an art form).

I am not saying that structure is bad. I am saying that there is a diminishing returns on this structure. On the one hand, you have something like assembler which has the least amount of structure. In assembler, anything is possible. Code is data, data is code, and you can jump execution to anywhere you want to. One the other end, you have something like WPF which has a high amount of structure. Yes, you can have a beautiful and highly interactive datagrid which bound to a SQL server in like 3 lines of code, but trying to do anything outside of what the WPF designers originally envisioned is nearly impossible.

Where structure comes in real handy is where technologies interact. An excellent example of this is the OSI Model which defines discrete areas of functionality within a networking system. These definitions/distinctions are pretty much self-evident if you think about it and they describe a very good (the best?) way to develop networking systems. In this case, structure enables development rather than retarding it. Another good example of structure is the concept of Interfaces. An Interface is all structure and no functionality. Interfaces allow you to define how two (or more) independent pieces of code will interact. Again, this enables development.

To come back to the article you linked to ... I like this guy's "compression-oriented programming" approach. I think it shows the proper way to introduce structure into the coding process. Design Patterns are a signpost for where you want to go rather than a blueprint of how to build it. Design Patterns are what happens after you go through the process that is described in the article. I think this is probably the message/intent behind Fowler's book Refactoring to Patterns. On the other end of the spectrum, WPF is what happens when you take Design Patterns too literally and start your coding from that point of view. Also, structure begets more structure. To code with WPF you have to use additional structure in the form of one or more toolkits and frameworks to really get anything done.

Coding is a creative process. It is fun. It is satisfying, rewarding, and empowering. Coding is about solving problems and there are a multitude of proper solutions for any single problem. Probably no solution is really better or worse than any other. As long as it solves the problem efficiently, who cares? Start with a bunch of code puke which solves your problem. Then go over it again and again, refining it, touching it up, perfecting it. It's never really finished. Like any other art form (e.g. painting, sculpting, writing, etc.), coding is an iterative process without any real ending. You just end up deciding its good enough and its done. Think like water and code like the wind.

Some code has soul and some doesn't. You can tell when you run across a truly fine crafted piece of software that has some soul in it. It is unique and is a joy to use. From the UI to more technical aspects, it solves its problems in its own special way. X-plore File Manager by Lonely Cat Games on Android is (I feel) an example of this. I don't know anything about it other than I use it every once in awhile, but I can almost feel the care and attention to detail that went into building it. It wasn't just pressed out of some framework's factory and slightly modified to adapt to a specific purpose. It stands on it's own and has integrity. It's got soul.

TL;DR: Coding is an art form. Structure limits freedom. Some structure can be helpful. Think like water and code like the wind. Code can have soul.

Can confirm, I am a developer of 30+ years. In general, developers love what they do and love providing value to end users. We want you to use our work. We want our work to be helpful to and enjoyable by you. The problem is the decision makers who don't understand or care about quality in the development process. While I suspect this to be true across many industries, I can only speak about the software industry. I have given up trying to reason with bosses and clients to help them understand the value of spending a little extra time and effort in the pursuit of quality. I think we have plenty enough technology now anyway. Don't get me started on the microsoft version churning bullshit. Those guys used to be good but they don't know what they are doing anymore. Enough.

I don't think the article said anything about personal problems. It is partly saying that trying to treat the development process as an automatable and regimented process is likely to disincentivize talented devopers. It is also speaking to the whole political correctness thing that is being taken to the absurd extreme that it is these days. I have been developing for about 30 years, am 100% self taught, am proficient with all of the popular languages and methodologies, worked in dozens of different companies of all sizes, and have simply given up trying to accomplish anything of real value. For about a year now I have worked a simple little part-time job. I have zero stress, and use all my extra time working with and on open source projects. The quality of my life has improved tremendously and I have regained the passion for development that originally started me on this journey so long ago. It's a shame really, but I am so tired trying to force square pegs into round holes for people who don't know what they are doing.

Since it was brought up, the original idea behind agile development is really good. The problem is when unimaginative organizations and managers try to force it down everyone's throat for every type of development scenario. And fuck the scrum bullshit.

Development is an art. Good development is done by good artists. The best development is done by someone who looks at the problem to be solved and selects the best tools and methodologies to effect a solution. One size does not fit all in development. This is what the corporate ass hats will never want to understand. They try to turn development into a science, where it can be quantified and measured. It just doesn't work this way.

Remember this the next time a piece of software ships with bugs or has otherwise senseless features. Or when a piece of hardware fails or doesn't talk to your other hardware. The next time you have a technology related wtf moment, you can probably blame some mid-level management retardation somewhere.

I suppose it could make it more convenient to develop and test Android apps if it were running in a vm. Then again, there are emulators. Still might have some value for research or as an alternative. Sometimes you don't realize the value of something until you've built it and have learned a hundred other things along the way.

Kernigan and Ritchie. Big memories ... werd.

Cloud9, for realz.

I've been using NetBeans for PHP/HTML/JS development for awhile and am happy with it. Best free environment I've found so far.