Learning journal (training day 5)

Future TWUers: many people travel in India outside of Bangalore on weekends. Buy your tickets a minimum of two weeks in advance, or ticket prices rise dramatically. Some stay in Bangalore and find other entertainments. The bar Geoffery's at the Royal Orchid is just next door, and has prices roughly comparable to what you'd find in a neighborhood bar in Chicago.

I should post the retrospective notes (perhaps using this? http://retro.play.railsplayground.net/)

Reticular Activating Syndrome is concept within neurolinguistic programming, which we had an open space on today. 

Training Day 5

Recap of Thursday last session: TDD, refactoring, hot keys, ping pong, unit test, JUnit, hamcrest, statics, methods which are there only so you can test them (are bad)

For those of us who are completely done with the curriculum, we can help with the setup for the project. Stuff like setting up Go, the repository, etc.

I learned that UK Macs have a slightly different key layout- just enough to screw up my muscle memory.

It is very important that we have a deep understanding of what null pointers are and are not, because interpreting error messages is a large percentage of what one does. 

Session on retrospectives:

We talked about the "safety check" exercise, where everyone puts a number from 1-5 (5 is comfortable, 1 is on the verge of setting the place on fire?) on a postit, crumples it, and someone comes around with a bag and collects them anonymously. Uncrumple them and put them on the board and see what the group is feeling..

Sometimes the safety exercise is followed by an anonymous round of "what would make you feel more safe?" (Sometimes the answer is for the senior architect to leave the room... or for the client to leave... etc and sometimes the recommendations are followed if the facilitator judges that that would be a good idea)

Make sure that your retrospection makes action items! Also that there are specific individuals' names on them- ownership is essential. Group ownership does not work. 

One of our number has a rather bad toothache, unfortunately. Current resolution is painkillers and soon a dentist. 

Future TWUers: consider making an excel spreadsheep of weekend trips, with columns for cost, organizer, activities, and dates.

We had an open space that included discussing several TED talks and their value as presentations. 

Why static methods and variables complicate everything

My most useful sources for this were:
rancorbeast
blog by misko
blog by jagregory

Unit testing depends on being able to set the variables which part of your program uses, and then see whether the part of your program which you're testing uses them correctly. But if what you're testing requires manipulating or reading static variables, the test cannot be written efficiently, because the static variables are static and hold their value for the entire run of the program. Because having static variables makes unit testing difficult or impossible, it is less likely that a programmer who uses static variables will use unit tests. This implies that their test may break without the programmer knowing about it, and that the programmer might not follow other best practices, since they don't follow the one about testing.

Static methods make code harder to change, because other parts of the code may rely on the static methods being static. This coupling makes your design difficult to change. Having a design that is easy to change (refactor) is good, because then you can refactor it to make it better. Static methods imply the presence or incoming presence of bad design because the programmer has not given thought to making the program easy to add functionality to, and to refactor. If refactoring and/or added functionality is tried in the future, the code may begin to accumulate workarounds to the static methods. This will make the code longer and more complicated than it needs to be.

Static variables make thread safety almost impossible to achieve because they are a shared state, which is almost always bad. Static variables, and anything they access, can be accessed concurrently by different threads unless you take pains to synchronize access to them. While you can guard them, if you have too many of them your design is harder to validate because the locking will be more complicated. If there are enough of them, then performance will suffer because of different parts of the program waiting for other parts of it to wait for locking to resolve.

what does hot dogging mean?

To hot dog is to do something to a computer which is unlocked and unattended. (Around here, we require that it be nondestructive, nonexternal (i.e. send no emails, edit no databases commit no code), and fast to fix.

We usually just switch the keyboard layout to Dvorak, and invert the screen (ctrl-option-command-8). It's simple, fast, and noticeable.

The purpose is to train in data safety- if you leave your computer unattended, anyone who wants to can look into your files. General etiquette strongly prescribes against looking other people's computers, but it's best to not leave things to chance when there is sensitive data involved- especially if you are not working surrounded by teammates who are all privy to the same set of secrets. 

Hamcrest

Hamcrest is a framework for creating matchers, allowing match rules to be defined declaratively. These matchers have uses in unit testing frameworks such as JUnit and jMock. Tutorial It is commonly used with JUnit.

Training Day 4

Today the last of our TWU students arrived, and the group spent some more time performing introductions. We had several sessions, including one on open source and being aware of legal issues. (We are encouraged to contribute to open source projects.)

Some more exotic ThoughtWorks history includes the tale of the ThoughtWorks RV, which sounds absolutely delightful but I understand that the coolness of it didn't make up for the lack of demand.

Future TWUers: the Royal Orchid serves delicious food. You will become spoiled. :) Also, their other facilites are convenient and well stocked, which you will probably be very grateful for at some or several points.

There is a small grocery store in H block which has a pharmacy in the back. I highly recommend the snacks they sell, as well as their selection of mosquito repellant products and their q-tips.

There was a live demo today about pair programming- specifically, how not to do it. It was hilarious and a very effective learning tool.

Future TWUers: do not underestimate the amount of preparation you should put into the history session.

Yammer

Is exclusive like facebook used to be- it's only for people with a company email address. I like the interface- it's simple and works well. Usage is growing but I'm not sure how it supplements or replaces other free-for-all discussion zones within the private company network.

I've been added to the TW bloglist. I've read the TW blog policy (thanks, Roopa!) and the part that says that I have to be interesting is only a comment at the bottom of the main document.

Feedback

My suggested draft of a communication from and to someone at a company (which is not TW or a client of TW):

I would say "If you look at your error message, it's caused by the fact that in the code you sent me you hard-coded the path of a file in your program to find a test file in your own system. This is not acceptable. It also implies that you haven't done testing with a significant test set, which is also not acceptable. Please tell me what work you plan to do on the two technical errors, and your thoughts on what I/Company can do to help you improve your quality of work on this project."

I think that my feedback is too harsh. I think if the "This is not acceptable" was taken out it would be better. However, the person being addressed has shown a lack of knowledge such that there is a need for very clear statements about what code practices are not best practices.

There's rather a lot more in the above vein, but this is the part that makes me most wonder what more I have to learn about feedback. 

TW Anthology

I learned about the TW Anthology today and checked it out on Amazon. Looks like they're a little expensive.

Training Day 3

A burn up chart keeps track of what the tasks are and in what stage of done they are. It is shared with the client, and it builds trust and helps to avoid surprises.

A lesson learned from the lego exercise: there was no user story for the body, but we had to build it in order to attach the legs to the head. Same for many parts of software. These are called nonfunctional requirements. 

In my opinion, Agile is just a zillion tiny waterfalls, with a customer on your shoulder.

As a warmup, we played charades, only the words were concepts from yesterday.

YAGNI - "you ain't gonna need it."

"every line of code is a libility."

Cycle: Estimate, plan, develop, showcase, retrospective.

The economic model of TW is based on where a $1 of revenue goes. There was a pi chart that had many parts. There are several types of overhead. Salary ia large part of total expenses. 

TW earns fees from clients. If the client is displeased with the work, or thinks that they will be displeased with the work partway through the project, they might not pay. As TWers, we have to do well enough at making good work and communicating with the client that this problem is kept to a minimum.

Fixed costs include rent and servers. TW treats employees as a fixed cost rather than a variable cost, which means that when times are bad TW doesn't just start firing people. "The biggest problem in this industry is getting good talent. Pushing them away (doesn't make sense)"

Operating expenses include the salaries of Legal and Recruiting. There are two kinds of overhead: overhead that goes towards any one country/office, and overhead that goes towards the company as a whole.

Types of deals in the consulting world: time and materials, fixed bid, and risk and reward (which is a combination of the above two, I think.) TW does mostly the first type. "TW charges more per hr than most other companies."

Risk and how it influences fixed price deals. Caps on time and expenses deals.

SOW = statement of work. It's a cost to fixed bids, and it's corrosive to the relationship...
The deal review process happens before TW decides to try to get a project(?): capability(can we do it), intangibles (new tech is good because it gives us an edge later), financial (how's the compensation).

Gross margin should be a certain number (but in the example we were shown, was below that)

On your first day on a contract, "what's in the contract?" (hardly anyone does this, but it might be a good idea?)

Differences between the UK and the US in how billing works- country customs and regulations(?)

Accurate timesheets confirm (or indicate a need for fixing) estimate quality.

A shadow is a non-charged consultant. It's a way to train a junior consultant and make them useful.

Blended rate

Wikileaks:

There will be a forum tor tech leaders and tech $ people at the Churchill in the Bay Area next Weds at 7pm their time, 8:30am our time. TW is sponsoring it. It's being broadcast live and we may be able to watch it if our trainers let us take time off during the work day to do that.

The boycotts of Wikileaks by various companies.

Lawrence Lessig wrote a review of the Social Network that goes into a case study about Nantucket Nectar and why the internet is a good thing in that context.

The subpoena of Twitter records in relation to Wikileaks.

Daniel Ellsberg, the guy who stole the Pentagon Papers, is 83 and still gets arrested at protests. This guy is badass.

Civil liberties group involving tech companies?