PUBLIC MARKS from greut with tag work

Hire the best, fire the rest

Hiring the wrong people cost:

• Time
• Money
• Culture

You'll never say it too much, trust me.

If you can’t remove yourself from architecture or design so that you can concentrate on managing the project, it’s time to choose. Either manage this project or become one of the technical staff. But don’t try to do both.

I'm not the only one to think that Architect and PM aren't playing well together.

After all, a cargo cult shop is imitating what they have seen about agile. However, like waterfall proponents, cargo cult agile shops are led by people who have looked at pictures of agile models, "read" agile books, or "learned" agile development from PowerPoint presentations. Perhaps there are a number of developers who know agile, but they may not be able to move the company towards agility in the face of generations of managers and developers who have been indoctrinated by DoD-2167.

the story of my life

In our research, we found that the most effective teams were skilled in all five styles, choosing the style that best fit the needs and goals of a project. For example, they might concurrently be involved in deep research on a User-Focused project, while relying on their experience for a Genius designed project, and spend a little time whipping out some one-shot functionality whose results would be Unintended Design.

Since the teams are working with different styles all the time, does it matter? Our research says it does. The teams that produced the best experiences knew these styles well and how to quickly switch between them. They knew when they needed to go whole hog and pull out all the stops for a User-Focused style project, while also knowing when it was important to bang out a quick design, knowing the results would essentially be unintended. Those teams had a rich toolbox of techniques and a solid understanding on how and when to use them.

There is no silver bullet.

Obviously fun coding projects aren't the only indicator of a rock star, but they're a good way to filter out programmers that just do it for a paycheck.

don't forget that those kind of employee are demanding, they know how to have fun at working (if they do that in their spare time). Give them good food.

A nice git workflow that shows how things get hairy when you're more than one working on something, a bit of an inspiration for setting up a collaborative/clean way of working imho.

Generally, in that group, there will be one or two loud voices. Maybe an Alpha Male or two. The important thing to note is that this is a small group. It will be difficult to reach common ground with a small amount of people.

ouch... that is my daily job.

This is an evolving web version of a book that I'm writing titled "Zero to Hyper Agile in 90 Days or Less."

a book as a blog.

A do-ocracy (also sometimes do-opoly, which is a more obvious pun on “duopoly”) is an organizational structure in which individuals choose roles and tasks for themselves and execute them. Responsibilities attach to people who do the work, rather than elected or selected officials.

do do do!

the evil is SVN itself not handling changing of externals (i.e. to/from an external) in basic operations like updates and merges, which may cause a lot of manual work on your end, and break automated builds or similar.

wondering about massively usage of it.

Her finner du oppgaver til alle kapitlene i Stein på stein. Vi vil etter hvert utvide nettstedet med flere oppgaver og gjøre det enda enklere å bruke.

Apprendre le norvégien

Her finner du oppgaver til alle kapitlene i Påvei.

Apprendre le norvégien

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.

Something more interesting than the usual Excel sheet

Developers hate three things, above all else, in increasing order of painfulness…

1. Working on stuff that is easy
2. Working on stuff that is tangential
3. Working on stuff that no one will use

no comment

The bigger point is that none of us are doing enough to challenge the assignment. Every day, I spend at least an hour of my time looking at my work and what I've chosen to do next and wonder, "is this big enough?"

how big can you think?

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

A more general approach that the SCRUM one I got so far.

Determine a basic need -> Create a service that satisfies it in the simplest way possible -> Open it up

it sounds all right to me too.

Django's templating system is often a pain to work with, and XML libraries for Python are also not stellar, so I decided to take advantage of Python's with statement and wrote a XML generation library somewhat similar to Ruby's Builder.

great example of the "with" usage

ResumeRDF is an ontology developed to express information contained in a personal Resume or Curriculum Vitae (CV) on the Semantic Web. This includes information about work and academic experience, skills, etc.

time for me to try xhtml/html5+rdfa

This series of layouts use pixel and em widths and relative positioning, and they work with all the common web browsers including Safari on the iPhone and iPod touch. They're also 'stackable' so you can use multiple column types on the one page.

liquid layout for the win!

Comet doesn’t have to be a hack. Currently, as we saw last time, Comet relies on undocumented loopholes and workarounds, each one with some drawbacks. We can make Comet work effectively in every browser, using streaming transports on subdomains of the same second-level domain, or using script tag long polling across domains. But this leaves Comet developers implementing (and more frustratingly, debugging) several transports across several browsers. Traps are numerous and easy to stumble into.

event-source is the future of all Comet things.

Not a line I draw ends up on an end‑user screen. Not a word I write is compiled into code. Not a sentence I say instructs users. I draw, write and talk to enable the specialists I work with to excel at what they do and realise inspiring software for my clients.

I’m not a graphic designer, I am an interaction architect.

Remember: Integrity is your main asset