Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

As a software engineer I have to learn to see things differently, because my job requires that I solve problems. Though not only is it important that I come up with a solution, but equally important that I can express the solution in code. [...] It is equally important to recognize that not all problems have technical solutions. Some problems are better solved by social solutions.

He talks about the influence that some of the major services have had on the social aspects of our lives and how they're mostly a "convenience to mankind". He suggests that the job of a software engineer has multiple aspects, and not just technical ones. They're required to see things differently, be able to understand the problem well and express the solution in a clear and practical set of code.

The engineer must figure out which problems are worth solving through technology, in order to save people time and money, and defer those which do not to more social means. Let humans do what they do best and computers do what they do best.

The Server-Side Magazine site has posted an interview (10 questions) with Andrei Alexandrescu, a research engineer currently working at Facebook.

Today we caught up with Andrei Alexandrescu for a "10 Question" interview. He is a Romanian born research engineer at Facebook living in the US, you can contact him on his website erdani.com or @incomputable. We will talk about some of the juicy stuff that going on at Facebook, so let's get started.

Their questions include:

What's your development setup?

What do you think of PHP as a language from your perspective, regarding that Facebook was initially written in PHP then transformed to C++ using HipHop for PHP. What are the pros and cons of using C++ over PHP at Facebook?

Currently, what kind of research do you conduct at Facebook? (or is this confidential?)

Tell us a little bit about the D programming language, in contrast to C, PHP, Ruby and others. In what fields can someone apply D?

Also, what kind of advice can you give for developers who are considering to apply to Facebook? What kind of skills is Facebook looking for in a potential candidate. Is it really important to be a graduate CS? What kind of skills do the majority of Facebook employees possess?

In this edition, I talked with Enrico Zimuel a computer geek since he was 9yrs old. He has written a couple of books namely "Secrets, Spies and Cipher Codes" published by Apogeo in 1999 and the recent "How to use the digital sign" published by Tecniche Nuove in 2010. Enrico has a pretty impressive 'geek' path. He also speaks at many international conferences [...]. You can find his presentations on slideshare.

Questions in the interview include:

How do you find PHP now as compared to when you first started?

Based on your experience, what are the good and bad parts of PHP?

To someone who wants to become a better PHP developer, what is your advice?

On IT World there's an interesting article about the programming skills that seem to be lost in today's coders and how what they may not know might hurt them in the end.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

With the idea of PEAR2 and Pyrus, I had hoped to see a renewal - the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme. [...] If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model.

He breaks up his thoughts on the future of PEAR2/Pyrus distribution into a few different topics - the issues he sees surrounding packaging (like static packaging definitions), suggestions for a dynamic channel aggregation system and overall usage of the PEAR system.

According to Chris Aitchison, you're not a "software engineer" if you write code an develop applications - you're a "software gardener":

The engineering metaphor has had its time in the sun, and maybe it even used to be accurate, but now it really only serves to help non-technical people have unrealistic expectations about how software gets built.

The post describes software development as gardens instead of feats of engineering. It talks about the organic nature of development, how no matter the course that's plotted, there'll always be things that can't be anticipated ("weeds") that will need to be handled. It's not about the technology behind the product (anyone can build the same bridges) but more about how its nurtured by the developers. It's an interesting perspective and I'd recommend giving it a read as well as the large amount of comments that come with it.

If you've heard all about the CodeIgniter Reactor project (the community powered branch of the popular framework) and have wanted to get involved, now's the perfect time. Because of a change in the ranks, they're looking for another Engineer to fill an open spot.

If you follow the Reactor team, you probably already know that the venerable Ed Finkler had to resign from his position due to personal time constraints. That means that we have an opening, so if you feel that you qualify, please email iwanttohelp at codeigniter dot com.

The email needs to include your CodeIgniter username, a link to your profile, three contributions back to the framework and a paragraph stating why you think you should be the new Engineer.

The CodeIgniter Podcast has (finally) released the next episode of their series - episode #5 where two Reactor Engineers (John Crepezzi and Kenny Katzgaru) talk about the project and some interesting recent additions.

Reposted from oconf.org, Reactor Engineers John Crepezzi and Kenny Katzgrau talk about their plans for CodeIgniter Reactor and talk about the idea of "sparks".

The sparks are self-contained, easy to install packages that bring additional functionality to the CodeIgniter core set of tools. You can either download the episode to listen or you can use the in-page player on the CodeIgniter Podcast site.

Today EllisLab and the CodeIgniter Reactor Engineers are proud to announce the first official release of CodeIgniter 2.0.0, which is being released in two flavors.

The "Core" version will be the branch that EllisLab uses for their internal applications and will be a bit slower moving. The "Reactor" branch, however, is more community-powered and headed up by a set of Engineers that will guide the framework and work to make it its best. Also mentioned as new in the post are the upcoming ability for users to contribute directly to the user guide, the creation of a standardized Authentication library and a more object-like model setup. If you're interested in the Reactor branch and want to try it out or contribute, head over to the bitbucket account for the project.