Archive of published articles on May, 2011

Back home

Relearning python, day 3

31/05/2011

The last few days were spent re-organizing my code and writing unit tests.  Here’s what I learned:

I was still spending too much time thinking about namespaces, privateness, interfaces, and organization.  Once I got rid of some ‘abstract’ classes that served no purpose (they’re not meant to be subclassed outside the library- so why bother?), stopped trying to hide things behind so many layers of indirection, and organized my code differently (didn’t have all my modules start with an underscore because I was so concerned about what I’d expose), something magical happened- the API was simplified.  It’s funny- creating simple APIs in C# often involves a ton of substructure that is all internal/protected/private- in fact, I think I excelled at making great public APIs, but they always involved a lot of private implementation (and that’s not just me- look at something like Enum.TryParse).  Creating a simple public API in python has the opposite effect- it seems to streamline the code and make it more explicit (as you’d expect).

Unittesting is awesome.  I still have a ways to go to learn how to write tests well, but that’ll come in time.  Unit testing gives me the benefits of static typing (ensuring what needs to be called is callable), and more (it tests actual functionality).  Doctesting is wonderful as well- I tend to test library/utility functions with doctest and unittest for everything more complex or things that have side effects.  I enjoy documenting in python far more than C#- I’m not sure exactly why, but having a much simpler usage and the ability to test/demo via documentation is great.  I enjoy the more flexible arbitrary string style of docstrings, rather than the heavier xml-style documentation in C#.  Almost everything I’ve written is tested, which is great (because it also means I am writing code that is actually testable and modular).

I can’t decide whether to use camelCasing or lower_with_underscore.  I prefer C#’s casing style, objectively (I liked it more even though I came from using camel-cased)- and MS is much more decisive on style, which means even if I didn’t agree, I’d adapt.

I want to start looking into multithreading and will miss .NET’s Task Parallel Library and ThreadPool.  I’ll start looking into stackless.

The biggest thing I realized is that python is a big paradox.  It is supposedly easy to learn and relatively simple; a great language for beginners.  But so much of good python programming is understanding convention, in that the language doesn’t force a certain way of doing things.  This makes python awful for beginners, and it has been my biggest criticism since I have been coding C#.  There is an awful amount of awful code written by people who have not gotten over the education hump.  C# and .NET force the programmer to do a large number of things.  They are good for teaching basics because you must follow these basics.  There is a lot more overhead to writing .NET than there is to python, and that overhead implies some more rigorous study.  There’s no convention- just static typing, and everything is an intellisense dropdown away.  Python requires more thought but less work, which means I feel incredibly liberated working in it.

 

1 Comment

Relearning python, day 2

28/05/2011

I got a few hours of python in on Thursday, and had three major breakthroughs.

First, I started using PyCharm, a python IDE from JetBrains, the makers of ReSharper.  I think, in many ways, it is better than Wing- I definitely prefer it.  I have a number of the code analysis, generation, and refactoring tools I was missing, and the IDE behaves more like VS with regards to intellisense and the working environment.  So I feel, once again, like my IDE is helping me.  Now if only I had Edit and Continue in the debugger…

Speaking of which, it made me realize, I need to start writing unit tests (second breakthrough).  I have never written any significant number of unit tests.  It is just a different mentality when you’re writing statically typed code.  Unit testing in python is just something you need to do- and I find it awesome, because I wish I had more incentive to write unit tests in C#.  I expect a lot of my time and resources to be spent learning how to unit test effectively.

The most important breakthrough, though, was realizing how much code I wrote in C# that had a sole job of trying to stop people from doing dumb things.  I read a post on The Endeavour this week titled Software Architecture as a Function of Trust.  It hit exactly what I realized just as I was realizing it.  Thursday morning, I deleted half of all the code I wrote Wednesday.  And, not surprisingly, my entire design was simplified.  Half of all my code was composed of classes that tried to manage what a programmer wanted to do, instead of providing actual functionality.  This is not unlike where I was moving in C#- do as little work as possible in your libraries and ensure the code is passing you valid state/data.  If they’re not, throw an exception as to why not (ie, in few cases would you want to automatically create a directory in your libraries- have the caller test/create it before they call).  In this case, I’m saying- I’m going to do exactly what you ask, and if it doesn’t work, the egg is on your face.  There’s no way to stop bad programmers from writing bad code- anyone can write a bogus implementation of your Interface that perhaps has some logically impossible state.  But what you can do is guide those programmers to use your system correctly, though unit tests and documentation.  Python code is more heavily documented than C# code, hands down.  Even a cursory look at what’s available makes it clear.  These things are part of the language as much as its syntax and grammar.

We forget how powerful of a motivator convention is and try to replace it with oppressive class hierarchies.  I’m much happier with my pythonic design from Thursday than my oppressive and static design from Wednesday.

3 Comments

Relearning python, day 1

26/05/2011

Yesterday, I started my first major python program, for aggregating together content from social networking sites to post on tech-artists.org.  Holy.  Shit.

The first problem is, I got very used to (and good with) Visual Studio and Resharper.  I’m using WingIDE right now but am going to look at using Eclipse and PyDev, because working in Wing after having used VS/Resharper feels like I went from being an octopus to a jellybean.  The time from inception to expressing my thoughts in code is undeniably and significantly longer- worse intellisense, worse customization, less debugging facilities, worse code generation/refactoring tools, no realtime code analysis (I am going to get pylint set up in Eclipse, at least).  But that’s not the real problem.

I’ve done python before in a ‘scripting’ capacity.  Writing a module to do some specific task, like write out a file or process a file or wrap a .NET library.  This is different- I’m designing a system/framework.  And I have a big problem.  See, I’ve been doing this in C# for years, and think I got very good at it- highly immutable systems with properly designed objects written against interfaces.  My flow has normally been, write the interfaces, implement the interfaces, move methods onto/off the interface, keep a close eye on the public interface, repeat until I get an abstracted design I’m happy with.

This doesn’t seem to work with, or hasn’t caught on with, the python community.  Look, I’m very happy I can write less boilerplate code.  I am.  But I’m much less happy that, when I change a class or member’s name, signature, whatever, I need to apparently clean up references manually (via textual searches).  Refactoring is much easier when I can determine actual references, and Resharper can do a textual search to guess if I’m referring to it in strings (docs or reflection).  I’m much less happy programming against classes, rather than interfaces, because for me this is a logical coupling (whereas an interface decouples).  It isn’t the warm blanket of static typing I care about, it is the concrete benefits that static typing provides, that I am missing (tell me if I can get them back!).  And goddamn it, I miss read only properties and fields.

Here’s what I know I need to improve- I need to get better with my IDE so I can learn how to refactor python code effectively.  I need to relearn how to organize code effectively.  I need to program against custom classes less and use more basic types (or classes inheriting from basic types).  I need to care less about required immutability or learn how to do it.  I need to write unit tests (and learn how to use them in my IDE) since that is a required part of python programming.  I need to find where to look for best practices and real good guidelines, because even with all the blogs I’m subscribed to and sources I’ve read, I’m seriously missing something.  And I can’t wait to get to CCP so I have people to answer questions!

Lots more to say in future days.  How often does this abrupt switch happen in the real world?

4 Comments

C# is out, python is in

24/05/2011

At BioWare, I pretty exclusively used C#/.NET.  I consider myself a talented .NET developer and have spent a lot of time reading books, blogs, and exploring new technology and techniques.  I’ve dabbled with other languages (and used them where necessary), but I’ve always fallen back to C#.

CCP, though, is a python/C++ house, and I have no desire to try to push .NET there (even if I could).  So I’m entirely leaving .NET behind now and moving forward with python.  I have a lot to learn- fortunately, I think I’m a good enough developer that I no longer need C# to hold my hand.  I think C#/.NET is an excellent platform, especially for learning- the framework helps speed up development by including a great library and it manages memory for you, and the language forces some degree of structure on your programs.  Python has the same benefits but forces less structure on your programs.  This is, in my opinion, bad when you are learning but great when you are done dealing with the clutter and boilerplate those languages impose.

So, after being a diehard C# developer for the last few years, I’m ready to leave it all behind and jump headfirst into python.  I’ve already been updating my blog rolls and going through some great books for months, but I know I have a long ways to go.

2 Comments

The right kind of consistency

22/05/2011

Code consistency seems like a straightforward topic.  And it is, when you consider just the code.  But you have to consider the team behind the code and the long term evolution of the codebase.  The best architects will enforce consistency in the right area at the right time.

The ‘time’ aspect is particularly important.  Consistency at the current instant in time is important.  The team as a whole should be of a consistent mind with those things that are agreed to be consistent.  But what is ultimately a huge negative is consistency over a long period of time.

This problem manifests itself from minor to major consistency issues.  On the minor end, let’s say you prefix all members with ‘m_’.  You realize later than ‘_’ is shorter and much easier to type.  Why not just switch over to ‘_’, if your team agrees it is better (and who wouldn’t?).  If everyone agrees, then you don’t have to worry about ‘competing styles’, as often happens if you don’t have a uniform style.  You’ll have more code edits as you change over styles, sure- but these are minor and trivial edits (and very easy to diff/resolve/merge, if that’s what you’re worried about).

On the more major end, you have something like not allowing early returns.  Again, there’s no reason to enforce this rule for the sake of consistency- debugging with early/multiple returns is no harder.  What is clear, though, is coding with less nesting is a benefit (nesting increases the cognitive burden placed on the reader since a single line of code seems actively dependent on more states- there’s good writing about this if you want to investigate).  But mostly, having one return in a method is another outdated C++ leftover.  So why sacrifice all new code because the old code, conceived in a more ignorant time, is inefficient?  Break consistency to move forward.

And that’s the key to the whole thing.  Consistency can stand in the way of progress. If current conventions are tenuous, don’t be opposed to changing them for the sake of consistency.  It is the consistency of the team and not the consistency of the codebase that matters. Otherwise, you end up only evaluating and improving conventions every several years, instead of every several months.  More rapid convention changes means you have more changes and chances to see what works and what doesn’t, find new things out, and move your codebase and team forward, inch by inch.

No Comments

A lead shouldn’t lead like lead.

19/05/2011

I’ve been thinking a lot about what I’m going to do with my new role at CCP.  Most of these I’ve been able to do (or advocate strongly for) to some degree even as a non-Lead but they were never supported enough by the Leads and never took hold.

  1. Training sessions.  These are vital for the health of the team in so many ways.  It exposes people to new ideas, stimulates discussion, and gets people thinking about things differently.  It also gets them contributing to the social aspect of the ‘team’ rather than just contributing files into a codebase.
  2. Collective vision and self-tasking.  I was always most frustrated when I didn’t have a say in what I was working on.  True scrumming alleviates this, but even without scrum, team members need to decide what the team is going to be working on as a whole and what they are going to take on in particular.
  3. Changing concepts/standards/practices.  Consistency in a codebase is great, but keeping a team motivated and passionate is more important, and will result in better code overall.  I think the current concepts/standards/practices should be consistent, but they need to change over time.  Developers change, and new ones join, and they have different opinions and better ideas.  You shouldn’t frustrate them by stifling superior ideas for the sake of consistency or resistance to change.
  4. Community engagement.  I don’t think you can be an excellent developer in this day and age unless you are part of the coding community- force everyone to have a Stack Overflow account and come up with a blog bundle for the team.  And then have a ‘reading group’ every week or two to cover interesting concepts.
  5. Move people around.  Never have your entire team sitting together permanently, and never embed a team member with a team permanently.  4-6 months at a time, and switch things up.  Expose your tool devs and TA’s to different groups, to get more context and develop more relationships, and then move them ‘back home’ to refine and refresh their skills.
  6. Code Katas.  Another team-building exercise that can easily be factored into training sessions.  Also useful to cross-pollinate teams, so programmers from different teams can pair and compete against their buddies.

The key here is: change.  As a lead, you are your teams biggest enemy.  You have the power to grow your teammates and the team, and you have the power to frustrate teammates and stunt growth, more than anyone on the team (you have the most power on the team, and with great power…).  You need to make sure the team doesn’t stagnate, and the way you need to do that is by integrating mechanisms to guide change into your every day interactions.

And in a year, I’ll be able to look back at this post and evaluate how well I executed on what I wanted to do- and if something is ill advised I’ll be able to judge why I didn’t realize it.

3 Comments

Cars, by definition, cannot fly

17/05/2011

Saying that you need to throw away years of work and start from scratch is rarely a practical solution.  And I absolutely agree, and am a huge supporter of trying to make solutions that work in context and are practical.  But there must be times when incremental improvements must be abandoned for the sake of a new direction.

You cannot make a car fly by putting a bigger engine in it or making it lighter.  The fundamentals of its design are different from a device designed to fly.  When you are figuring out whether you should salvage existing decisions and incrementally improve, or if you should throw it away and start over, you need to ask yourself- are you trying to turn a car into a plane?

Sometimes we have cars and all we need are faster cars.  And sometimes we have a plane and we just need a safer plane.  But sometimes we have a car and imagine if we keep improving the engine and frame, we can make it fly.  We can’t.

But it is also important that when you decide you want a plane instead of a car, you don’t just abandon all ground vehicles.  We’ve been flying for almost a century, but we all still drive cars.  When making these huge technological leaps forward, we need to remember how risky the approach is and make sure what we do is as backwards compatible as possible.

This is an always risky and passionate issue but lately I’ve been using this as a useful analogy.  Identifying the fundamental problems is always the biggest obstacle to implementing a vision, and first and most difficult is to identify and differentiate the truly fundamental problems from the merely difficult to solve.

No Comments

Async IO- don’t do naive async!

14/05/2011

This post comes from a response here: http://stackoverflow.com/questions/882686/asynchronous-file-copy-move-in-c .  The second-highest rated response includes absolutely terrible advice.  It says, just put the file IO on a background thread.  It shows a complete lack of understanding of how IO works.

When your do IO (reading/writing from/to HDD or network), the software thread goes to the hardware, and says, ‘hey, can you write this info somewhere’ or ‘hey, I need this info, can you get it for me.’  The hardware then takes that request and does something with it, and when it is done it tells the software thread (let’s assume there’s no caching or lazy behavior going on).  This entire time, the software thread is just waiting while the hardware does the work.

What you really want to do is have the software thread run to the hardware and say, ‘hey, can you do this for me, I’ll be back later,’ then run back to the software threadpool (where all the inactive software threads hang out).  And then it should be dispatched to do something else (like run another request down to the hardware, or some processing).  When the hardware is done, the software threads will pick it up and report it as finished- the software threads are never waiting around for hardware to do stuff.

Unfortunately async IO in .NET is cumbersome, so it is often not worth doing truly async IO.  So it still makes sense to do IO on background threads, but it is just inefficient and NOT best practice- hence this post.  Just keep in mind this is a vastly simplified version of what actually goes on, but it is important to understand it at least on some basic level so you can design efficient and fast systems.

No Comments

What I look for in a studio

12/05/2011

The job hunt that landed me at CCP was an interesting experience.  It was long and difficult- but fun, because I knew exactly the type of job I wanted and type of studio I wanted to work at.  The job I wanted was a Lead Tech Art/Tech Art Director job, no surprises there.  Where I wanted to work, though, had much more going into it.

I’ve been very vocal that the large and nearly uncontrolled growth of BioWare Austin gave rise to most of the problems and incompatibilities I’ve developed with the studio.  Limitless people and money can have serious negative long term effects on any organization (even if it ensures the success of a single project).  So I look for a studio that can actively manage these issues as a healthy and stable place to work.

  1. How large does the studio plan to grow and how quickly?  If it plans to double in a year and potentially double again, I’m out.
  2. Where does the money to grow come from?  Is it self-financed, or does it come from a publisher?  If it comes from a publisher, I’m wary- third party finances can be arbitrary, and first party  money can create a scenario where:
  3. Is the project ‘too big to fail’?  Is the publisher going ‘all in’ on this project?  If so, too much money will be given to the project to reward incompetence (because the game needs to ship- see this year’s GDC lecture’s slides  about rewarding incompetence).
  4. Has the studio shipped a project of a similar size?  If the target project will need a target team size of 3x more than the next biggest project, be wary- no culture or studio can handle the complexities such growth for a single project brings.

All these factors lead towards a single point: Money breeds incompetence. Those are things that freak me out.  Here are the pluses:

  1. Has the studio shipped a successful game with principles I agree with?  Ie, I’m looking for a studio that has released an original, successful game, or has a track record of success on what it’s worked on.
  2. Is there a humility and stability to management?  Who am I meeting with for the interview, and where did the current management come from (are there ‘I’ve been at one company my whole life’ or are these ‘I shipped two failed MMO’s at different companies but it wasn’t my fault’ types, or something in the middle)?
  3. What’s the bonus plan like?  This is to gauge humility as much as the financial aspect.  Mostly, what’s the difference in percentage of salary between senior level developer and CEO?  OK: 0%/0%, 100%/anything, greater than/equal to a 1-to-5 ratio.  Not OK: Anything less than a 1-to-5 ratio.  I believe it shows a lack of care and respect for the people in the trenches when management gets such higher bonuses, in addition to the higher salary, more stock, executive perks, and the ability to manipulate bonuses (buying companies, getting rid of merit increases, etc.).

At CCP, I found a company that fit perfectly with what I was looking for.  It was the only company of the half a dozen I interviewed with that I felt completely comfortable taking a job with- I knew it was what I wanted, exactly what I was looking for.  It is great to feel like I’m going to a company that has ideals that align with mine, and I can have some confidence that those ideals won’t change in the near future (I hope I don’t eat those words).

3 Comments

From one space MMO to another

10/05/2011

By now it is common knowledge amongst those that know me that I am leaving BioWare Austin and Star Wars: The Old Republic for a job at CCP Iceland as a Lead Technical Artist working on EVE and their Core Technology Group.

This job change also entails a change of roles, from a senior role to a leadership role, which I’m psyched about.  I’m taking a position where I can do the things regarding culture and vision that were difficult or impossible to do at BioWare because of my role and the culture there:  the studio is too caste-based for my tastes and I was outside of the management and leadership castes, which limited my ability to change anything.

I’m also stoked to be working for a studio like CCP- the single thing that attracted me most to the job, and convinced me that an international move would be worth it, is the studio culture.

In the coming months, I hope to talk more about both studio and tech art team culture issues, and the higher-level pipeline design issues, that are my passion and, hopefully, a large part of my new job.

Also, I’ll be in Austin late June, if you want to see me before I leave for Iceland.

5 Comments

Switch to our mobile site