The most insightful thing was that historically we put too much unrelated things into the same bucket:
More background is in Chuck Connells article on Dr.Dobb's. Including The bright line in computer science:
When you follow the Samurai Debugging technique, you start with a blank screen. That's not what you want, so you start debugging it, and you continue debugging it until your program does exactly what you want it to do.
I don't think you can count someone even as a semi-decent java dev until he wrote his very own web framework at least once in his life (from here)
"Humans and higher primates share approximately 97% of their DNA in common. Recent research in primate programming suggests computing is a task that most higher primates can easily perform. Visual Basic 6.0™ was the preferred IDE for the majority of experiment primate subjects."
BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.Watch his talk for an explanation of this definition...
The foremost feature of Maven that comes to mind is probably dependency management. Maven probably standardized dependency management for the Java platform. That’s probably also the reason for its wide adoption.
At this time there are already several attempts for smaller and easier solutions that repackage the ideas about dependency management from Maven. Their promise is to be a cleaner and easier to use.
I think these examples are an impressive demonstration how the Java platform grows and how good ideas and concepts are adapted and evolved.
We're still figuring this stuff out. All of us.and
When no one knows what's "correct", people with confidence generally win the discussion.
You won't get everything you want!
Scrum is like a roundabout
Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.
- Eric Evans at SET 2008
Hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job.
- Educate Developers Instead Of Protecting Them by Davy Brion
Making development "safe" for lesser skilled developers by taking choices away from developers [...] does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I'll say that there is a silver bullet(s), it's: Skill. Knowledge. Experience. Passion. Discipline.
I think these tools work best for lay people (thus, your link to LayProgrammers). However, in general, tools like this slow down experienced/power users. [...] I would much prefer a markup language I could use to directly define stuff, with macros, snippets, and all the other things I'm accustomed to as a developer. As these tools grow, they get unwieldy (perhaps because they are ceasing to be domain specific enough?). [...] APIs in programming languages scale much better, with several orders of magnitude more density before they become hard to navigate. All the best-practices and tools don't exist there: refactoring, levels of testing, etc. Also, you loose the connection to text, meaning that macro facilities either don't exist or complex one-offs. [...] I share your bullishness around these types of tools, but they are a long time from being useful for full-bore Agile development. I hope they mature fast.
Contents/Info.plistwith a text-editor.
Info.plist(just before the ending </dict> </plist>)
qlmanage -ron the commandline.
To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful.
Architects, designers, and developers of corporate systems usually have little or no voice in what gets built, or how, or why. They don't sign on, they get assigned. I know that individual developers do care passionately about their work, but usually have no way to really make a difference