cam-

iirc there was one guy for a long time who handed out the au domains. I think he was at USNW or USyd?

Yeh way cool, you don't need a driveway or garage then. It would be good to reclaim that space.

Can't wait until self driving cars become the norm; I don't need a drive way, a garage and the suburb I can live in can have smaller roads with the space for cars given over to walking paths and bicycles. Maybe in 2050.

We have one instance where we update an account, that goes out to potentially 11 service calls which are not transactional. We are having to maintain state in our app because the micro services have split this up so much.

We do hackathons at a local craft coffee/beer cafe. I usually turn up with between 4 to 12 engineers and they all get coffee, beer, food on an expensed credit card. The guy that manages the place told me we could reserve tables like conference rooms if we wanted. Pretty cool.

Software development has become a social activity. The way we organize work is all social; scrum, kanban, swarms, hackathons, etc. No real way around it these days.

We did a hackathon today. Several things made it a successful hackathon. First; a Product Owner ran the early brainstorming and problem setting. This made a big difference. The engineers were coming up with new products but with the discipline of what works in defining a real product.

Next they broke up into teams of two or three and worked on a specific product idea or feature/improvement. There was a break in the middle of the day when everyone had lunch together, and then back into coding afterwards. The hackathon started at 9am and ended at 4pm with every team having working features to demo.

At least one of the features demo'd will go straight into the existing product, the others will be demo'd to other stake holders and will most likely end up in the existing product but as a more polished feature.

So in summary having a Product Owner over see the brain storming, having everyone work in the one branch together in small teams, and making the new features or products demo'able by the end of the day.

Integrating lots of points is a pain in the ass. Integrating a new service was a 13 in a sprint. Adding a field to an existing service is 3. Often the aggregation gets pushed into the front end layer as well so the customer workflows get mixed with the service logic. Which is not pretty.

I have clicked on most of the landing pages that have been linked in the comments and they all look the same.

Unit testing is a leading indicator. The higher the coverage the better the quality of the product is a good broad rule. Engineers hate unit testing to 100% until they do, and then they don't go back, it becomes the norm for their development process. The confidence and assurance you get from that level of coverage is amazing. It takes the stress out of software.

I agree. Politics is how people negotiate power without violence. So it is everywhere. It always helps to understand politics even if you don't want to engage in it as it can help make seemingly irrational behaviors appear concretely rational once the motivation for it is understood.

Front End teams tend not like micro services, there is too much overhead in getting too little data. As an example we integrate with one micro service where get back a boolean and and a date. We have the overhead of an http call and all the error handling that goes with it for two pieces of data which would be better aggregated into another service. We story point an integration with a new service as an 8, but adding a new field (or two) in an existing API data structure is a 1.

I hope micro services is not just a new fashion in software and is actually useful ten years from now.

If we get several bugs or the team recognizes that an area is becoming brittle we make a bug that one/two team members work on for the sprint to clean that entire area up. The PO has become used to these kinds of bugs/user-stories and prioritizes them.

Java has been round long enough to have been influenced by whatever was the coding fashion of the time. You can see it in the core java libraries and the supporting frameworks. OO and GoF where probably the biggest fashions and you can document when a core library was written by the approach to it.

fwiw in one on ones I go over all the tasks/responsibilities of the next position above them, and we see if they did any of those kind of tasks in the last sprint. If they did we record them. We also look if there are any opportunities to do tasks in the next level above as well so they can be assigned that work in the next sprint. That waY i can make a strong argument when the person is ready for a promotion too.

Ungraciously it could be argued that atlassian's tools fall in the time waster category as well.

Everyone just 'knows' what is in Sarbanes Oxley but when you ask them to point it out to you in the legislation they cannot find what they were so certain about 2 minutes prior. We have compliance people and auditors are always coming in, but when someone claims something is required for Sox compliance, challenge them on it as 99% of the time it is a convention because someone told them, or they did it like that somewhere else once, rather then what is required by law. At the least it will make them justify the compliance/overhead they are causing you to do as an engineer.

Here is the legislation if you want to read through it or use it to challenge someone's assumptions about the Sarbanes-Oxley; http://www.sec.gov/about/laws/soa2002.pdf

fwiw we make people who are interviewing do unit tests on our production code. We have enough old gnarly code that we can always find something that doesn't have coverage. It is a great way to see how they code, how they interact with unfamiliar code and how they get on socially with the person doing the interview.

When compressing javascript down, missing a semi-colon can cause broken js, especially in older IE browsers. Trailing commas on js object literals would also freeze an entire page in IE. When that happened it would often take several days in jslint trying to work out where the broken js was from.