![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
Top Linux Developers Losing the Will To Code? 170
E5Rebel noted that Don Marti has a piece that talks about "Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex."
This is Bad? (Score:4, Insightful)
Perhaps the less coding you do the higher you get up in the management ladder is for a reason, after all...
Comment removed (Score:5, Insightful)
Re: (Score:2)
Better management... (Score:2)
Getting older and coding (Score:5, Insightful)
As far as older, I don't think age has much to do with burnout. I started a major open-source project after the age of 40, my first big programming project after a career change. (I am one of the few managers that then became a coder.)
I am now pretty burned out. It isn't that I can't write code -- in fact, I am better than ever. I just don't *want* to write code any more.
Re:Getting older and coding (Score:4, Funny)
I feel your pain, brother! I've spent my entire career not wanting to write code. Thankfully, I took a dev position at SCO.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Fresh thoughts and fresh minds, those who have been at it for a fair while can sence the eagerness of the newcomers and know they need to shift the contribution to areas where their experience will be of greate
Stop coding, start designing (Score:3, Insightful)
First it was the technical challenge;
Second the challenge was to earn money from my skill (not very successfully)
The challenge for me now is design.
I see free software as an art, code is just the medium in which a design is implemented.
I dont care if my project has fancy features, i dont care if time spent on it can be justified from a commerical perspective. Its just about solving a problem that people (developers
Re: (Score:2)
Luckily, my coding gave me enough money that I can afford to spend a lot of time on that. I still work, but about half-time.
This is Good (Score:3, Interesting)
Experience does count, and age is not a limitation. There's a myth that older people can't program. At 45 I reckon I can outprogram most youngsters, but it is probably more valuable to be mentoring others. I know a few very active programmers in their 60s and even 70s.
Old good prog
Re: (Score:2)
will has nothing to do with it (Score:5, Insightful)
"That's all I do, is read patches these days," he said during a discussion at the Linux Symposium in Ottawa last month.
This doesn't read "I don't want to code" it reads "I haven't time to code"
Re: (Score:2)
Re: (Score:2, Insightful)
> easily swappable
This is what most companies get wrong.
Coders are not easily swappable, no matter how much policy
you try to set up: the differences in skill have a
tremendous impact on the quality of the code, and if a
more talented supervisor must always veto/fix the code of its
underlings, it is a waste of time for everyone involved.
Only good coders should work on the code base in any position.
Those who also show management skills should get bur
Re: (Score:2)
It doesn't take a genius coder to implement a driver by a specification, or write then run some tests based on suggestions,
Re: (Score:2)
Sure... if it compiles, ship it.
a good or bad thing? (Score:5, Interesting)
I think the question is more ... (Score:5, Insightful)
Once you become a guru coder, you may write less code yourself, but you may approve more code over all. That would be code written by other people that you check, tell them where the bugs are and they fix the bugs and re-submit the code.
When the code is up to your standards (and the evidence is the flat rate of bugs) then the code is included in the kernel.
There was a time (long ago) when Linus wrote ALL of the code himself. If you look at just that metric, Linus barely writes anything anymore (percentage-wise).
Re: (Score:2)
Re:I think the question is more ... (Score:4, Insightful)
This of course implies that code is now checked more times and more carefully BEFORE inclusion, which is a win for everyone.
Re: (Score:2)
Re: (Score:2)
So? (Score:3, Insightful)
This is what happens as projects get bigger. It's not that they lose the "will to code", it's that they spend all their time as managers of other coders. There's more to developing a large codebase than writing the code after all.
Will? (Score:5, Informative)
Re: (Score:3, Funny)
Git (Score:3, Insightful)
I wonder are the rest using it... I wonder are the rest even delegating.
Re:Git (Score:5, Informative)
Re: (Score:2)
Re:Git (Score:5, Insightful)
Bouncing the patch back to the original author is exactly the correct thing to do. There's no way that Linus can be as familiar with the patch code as the person who wrote it, so why would he think that he could do a better job integrating than the original author?
Re: (Score:2)
Re: (Score:2)
It's just maturation: projects evolve (Score:3, Insightful)
Nothing to worry about. It's natural.
Everyone can help in some way. (Score:2)
Everyone can help in some way. The newbies who read the "Linux Recipes" online and point out areas of
Re: (Score:2)
In spoken English, pitch, loudness and timing are all used to indicate grammatical structure. Notice how your voice rises in pitch at the end of a sentence when you ask a question? Yet it falls when you make a statement. And everyone knows that writing in all capitals is SHOUTING! (I once told someone who was a bit ignorant about technical matters that sending text messages in all capitals would drain her phone's battery more quickly. She believed me -- for just long enough to get into the
Not loosing the will (Score:2, Interesting)
Re:Not loosing the will (Score:5, Funny)
I'm loosing the will to spell.
Re: (Score:2)
Try the following instead:
http://www.newscientist.com/news.ns [newscientist.com]
http://www.economist.com/science/tq/ [economist.com]
The Mythical Man Month (Score:5, Interesting)
Re:The Mythical Man Month (Score:5, Insightful)
It isn't. A few filesystem developers might have to make changes to elevator, or allocator code, but most developers of XXXXfs don't really need to make changes outside of that directory. Developers writing a driver for the XXXX model scsi controller, don't really need to interact with the people mucking with Alsa, or gart, or whatever.
The kernel might be contained in a single source repository, but it's really a few hundred, mostly-independent software projects.
Re: (Score:3, Insightful)
Need a newer version of the USB subsystem, or a fix to a driver? Have fun downloading a new version of Linux, which has an ungodly number of changes across the entire kernel.
People tend to think of monolithic/micro kernel only in terms of run-time technical advantages/disadvantages. But equally important IMO is the impact on development processes. With a good microkernel architecture, it would be totally reasona
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That's a really excellent book on software engineering. One of the best ever written. And while I think that formula is fairly accurate I also think there have been advances in techniques for writing software that allow you to get away with much thinner communications channels in many cases.
For example, someone here mentioned that the kernel was really several different largely independent software projects. And while I think this is something of an oversimplification, I also think it's true.
As another
Book needed (Score:2, Offtopic)
Granted if you're a good enough programmer you can traverse the source tree and pick up things on your own, but that is very time consuming versus "here's a quick overview" then look at the code for specifics.
Re:Book needed (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You mean like http://www.oreilly.com/catalog/linuxdrive3/ [oreilly.com]?
Re: (Score:2)
Just a little searching on Google and Amazon netted me the following two titles:
The resources for understanding the Linux kernel are out there, you just have to have the motivation and interest to look for them.
GregKH driver tutorial (Score:2)
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial/ [kroah.com]
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial_example_code.tar.gz [kroah.com]
Re:Book needed (Score:5, Insightful)
This is why the current fluid kernel/driver interface specification is unsustainable and unmanagable in the long term (and why ultimately the kernel development process will bog down).
The solution? Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version. Then the kernel developers can concentrate on the pure internals of the kernel which no-one but them should need to know about and the work which currently takes place to recode the hundreds of drivers each time there's a tweek to the driver interface could be redirected to more productive efforts... and the patch load should be less as well.
There is a side benefit to this as well, the energy barrier for 3rd parties to write drivers would be lower and hence it would be far more likely that they'd actually write them rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.
I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers." There will also be those who believe the dogma of, "but the driver interface needs to change often so as to be Better(tm) so you can't set the interface in stone."
Antithetical. (Score:2, Insightful)
Re: (Score:3, Insightful)
If a company can assign programming resources once off for a driver project and not have to spend extra resources every few months just because of a change in the kernel interface then they will look far more kindly on the idea of develo
Re: (Score:2)
Separate the drivers currently in the kernel source ball out into a separate project and define a kernel/driver programming interface and that work is decreased hugely. The side effect would be that hardware companies would find it far easier to develop and maintain drivers so that their management may actually think it worth the resources they can afford to give it. Again, this has nothing to
Re: (Score:2)
Nah. A lot of the basic stuff stays the same. And time invested in something that's changed isn't wasted time--an understanding of the old interface will probably help learn the new one. And I'll second the recommendation for the "Linux Device Drivers" book, it's good. See also lwn.net's kernel section f
Re: (Score:2)
While it's true that driver interface change, usually those change only impacts some drivers not all.
>This is why the current fluid kernel/driver interface specification is unsustainable and unmanageable in the long term
In the *very long term* maybe, but currently the amount of code changed each day is accelerating not slowing, so apparently it's not too painful yet.
In the long term, yes I can the see
Re: (Score:2)
Re: (Score:2)
An inevitable outcome of growth (Score:2)
Maximize value (Score:2)
As much as technical guys don't want to think about it, good management is an excellent productivity multiplier, alternatively no/poor management is a productivity destroyer.
Some well directed management and control will often result in the team getting more additional work being done than if the "manager" did it himself.
Think about all the times the senior guy, or the suits rejected blocked or other
Not only is this natural but it is also Good (Score:2)
I am sure that they miss coding but are they working on linux to satisfy their own coding desires or to make linux a better product. If it is the former then they have no reason to be in management, but if it is the later then they are needed where
this always happens (Score:2)
Welcome to programming (Score:3, Insightful)
Where's the beef? (Score:3, Insightful)
BillSF
Not news, this is normal (Score:2)
Circle of life! (Score:2)
Stop the presses! (Score:2)
Wow.
Management is just another form of coding (Score:3, Insightful)
Decaf ! (Score:3, Funny)
http://web.archive.org/web/20030620163003/http://
Reviews are important (Score:2)
Reviewers are often unrewarded for their work. At the end of the day, person who wrote code takes credit, not all those nitpickers who helped raise the code quality.
Wii? (Score:2)
Fundamental Flaws (Score:5, Insightful)
Some examples: OS X. In ten years or so a fairly small team has taken BSD and turned it into what it is. In over 12 with Linux I still see many of the same issues and problems persist... why? Because Apple *focuses* their efforts and the entire project is properly managed and steered. Imagine with the same focus and direction what the huge amount of OSS talent could accomplish?
Interoperability. Most applications are one-off programs made with no thought or care as to how it fits in the bigger picture. Unification, interoperability, and consistency are very important.
Fleeting Nature. Projects worked on while in college, hosted on random servers, work/girlfriends/distractions. These all can bring even successful and popular projects down overnight.
What needs to happen is to work under a single focus to create the most perfect distribution possible with clearly defined goals and concepts. Democracy, choice, and chaos have their place and they can be utilized still... just with some oversight and management before it goes live. Once there is a very good foundation (such as how OS X is now) then folks can branch out and work on their own projects and offshoots. I'm not suggesting that all choice needs to be eradicated, just that instead of trying to build a million individual sandcastles on a foundation of Jell-o we could be building a mansion on a sheet of bedrock.
The talent is here, the passion is here, the momentum is here... the oversight and direction is not.
Re: (Score:3, Informative)
OS X. In ten years or so a fairly small team has taken BSD and turned it into what it is.
More like 20 years. OS X is NeXTstep [wikipedia.org] with a facelift and a few years of minor revisions. NeXTstep development began in 1986 and the first release was in 1989. Not only that, but a typical Linux disto is significantly larger than OS X, since it includes a large variety of applications that Apple doesn't include in OS X, and many of which Apple doesn't even make.
The pace of Linux development is phenomenally fast, in spite of (or perhaps because of?) all of the false starts and dead projects.
Imagine with the same focus and direction what the huge amount of OSS talent could accomplish?
With focu
Re: (Score:3, Insightful)
You honestly believe that 300 half-working yet-another-whatever-app that is just as buggy as the other 299 is better than 1 or 2 excellent apps with more eyes and talent focused on them? There is a point when a million and one false starts gets exasperating
Re: (Score:2)
And therein lies the problem with your post. To many open source developers, it is about fun. Maybe not in the strictest sense of the word, but these are people who, for the most part, are spending their own free time doing something that they want to do. Telling them t
Re: (Score:3, Insightful)
You've glossed over the fact that nothing from NeXTstep just showed up magically working on BSD, it had to be coded from the ground up new.
I'm not sure whether you're talking about the original development effort or something more recent. Just to be clear, NeXTstep was always on BSD.
In any case, your rant completely misses the point. You came closest (by virtue of being most wrong) when you said:
This isn't about FUN it is about being part of something greater, and the fun you sacrifice to be part of it instead of going nowhere by yourself is reaped tenfold when you get to the end and see what a huge impact you *helped* to create.
There are a lot of OSS developers, and they all have their own reasons, but FUN is a *huge* part of it for most of them. For example, I'm a professional software developer, have been for nearly 20 years, and I often find that the stuff I work
Re: (Score:2)
Re: (Score:3, Informative)
also want to have "fun" and working on something cool when I write OSS code... but that doesn't mean I can't be working inside of some sort of high-level constraint or with some design/integration in mind
The only issue I have with this is that it implies that OSS programmers typically aren't working with some overarching design in mind, and that simply isn't true. Spend some time on project mailing lists looking at how many patches get rejected because they don't fit within the architecture and development approach. Successful OSS projects have a ruthless focus on maintainability, which absolutely requires consistent application of well-defined architectural constraints.
I'm saying there needs to be visionaries with a full view of the big picture and then it actually makes it easier for everyone else from there down.
People are certainly welcome to
Re: (Score:2)
In that same vein, you are minimizing management which is c
Re: (Score:2)
To be fair, Apple is able to do what it does because it can afford to throw bails of cash at the most talented people available to g
Re: (Score:2)
The real issue is the fact that everyone wants their own sandbox, and not to be told what to do or when. It is the wild west. And while so many people think that is kewl and fun, it is inefficient and a waste. Imagine a company running that way, even the best local food co-op's have
Re: (Score:2)
You're automatically assuming that everybody wants one "Linux". You're wrong. It's way more complicated than that. Your push is just one more example of "if only we had control everything would be more efficient" beloved of growing bureaucracies everywhere.
Instead you should be concentrating on standards, one at a time, as many people already are. Everything from the Linux Standard Base to the Free Desktop Project to the Linux Embedded Consortium. Keep in mind that if you're going to promote standards, on
Re: (Score:2)
We don't need government, we need guidance and steering and direction from some p
Re: (Score:3, Insightful)
The strength / weakness of the Open Source model is that it collapses these structures into a flatter skill space. On the bright side, coders get to scratch their itch and prove that their employers' architects are simply wankers that hold them back. On the down side,
Re: (Score:2)
Your best interests are not my best interests (Score:2, Flamebait)
I don't want to build a mansion. I like my sandcastle. If you don't, piss off.
Re: (Score:2)
I know you were just trying to be a smart-ass AC, but let me add this... In the same way that I (an individual person) cannot have all of the answers, neither can a lone developer no matter how good their intentions. You need
Natural Evolution (Score:2)
Once the product / project grows, the early gurus are needed to lead the direction of the larger group of developers brought in as the company expands. The new guys don't have the understanding of the big picture, so they focus on a specific area, and the best of them bubble up as they get more experience.
In open source, you don't have the same strict reporting relation
Don't feed the Taco troll (Score:2)
When you see a post with the name TACO on it, you automatically know there is a 70%(I guessed) chance it is taking at least a subtle jab at Linux or pushing Apple.
Where is the feature to moderate the Taco and Gang? (some are better than others)
Re: (Score:3, Interesting)
That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.
With all these fancy-arsed "designed so mistakes are impossible" languages
Re: (Score:2)
Re: (Score:2)
But PHP seems awfully popular. Or should I say terribly popular?
I can't decide...
Re: (Score:2)
Re: (Score:2)
Then you run afoul of Mitchell's Law of Committees, which states that:
This appears to be an incorrigible problem with human nature and is not unrelated to the fact that it is easier to obtain forgiveness than permissio
Re:Should have used Eiffel (Score:4, Insightful)
Perhaps you need to get a little deeper into kernel development to find out why Eiffel is a bad choice:
In summary languages that do stuff for you behind the scenes suck for kernel development.
Re:Should have used Eiffel (Score:4, Informative)
You're right, you wouldn't. People who spell it the modern way, Lisp, however, would [wikipedia.org].
Oh, please (Score:2)
Re: (Score:2)
In my frequent Java work I get by just fine with its DbC, that is its type system, Eclipse' static analysis, 'final' keyword, and assertions. I can't remember the last time I had