We're going to be rewriting the code from the ground up in Java. Then, we're going to make it fun. I'm excited.
legacy
Nick and I will be working together on Legacy. Legacy has been a side project for a while, something we worked on at home for fun. Annie's done a lot of art for it, Doug has written a lot of lore for it, Isaac and Katie even helped a bit! I've been steadily chipping away at it for a long time.
why so serious
I think one of the reasons I drifted away from Riot over the last couple years is my aversion to seriousness. This personality trait comes up again and again in my internal account of my life, and I'm sometimes conflicted about it. It certainly gives me something to prove.
One of the things I'm most relieved about is that I can leave Riot's inevitable transition to seriousness* behind me. I don't think it's because I can't compete technically, on the merits. I think it's much more that I find it tiresome to worry about every little thing. My style is much more "deal with it when it's a problem" than "figure it out upfront."
In my long term dream, the castle, I live the life of a gentleman-artist. I dabble in whatever interests me. I continue to work hard and learn. But the things I want to build are zeppelins, submarines, secret passages, towers on islands in lakes, underwater fortresses, aquaponics, tropical greenhouses in the snow..
It's difficult to tie that kind of whimsical vision to a big company. I often experience seriousness as a one way street. It's easy to get more serious, hard to get less serious. It takes real discipline, optimism, and trust in order to maintain a fun, creative working culture where mistakes are celebrated. I think it's extremely difficult to have that environment at a big company, for reasons of human psychology**.
If I'm willing to accept that I have the mentality of an artist but the skills of an engineer, then it seems that software engineering at a big company isn't really for me. Developing little games is the closest thing I've found to being paid to do what I want. Making my own game seems like an inevitable path.
*I don't think it will stop being fun to work at Riot, more that it's gotten so difficult to push stuff live. When I arrived, associate engineers could push code live without any real process at all. I'm more comfortable in that kind of environment, even though it may not be appropriate for a product the size of LoL.
**monkeysphere.
One of the things I'm most relieved about is that I can leave Riot's inevitable transition to seriousness* behind me. I don't think it's because I can't compete technically, on the merits. I think it's much more that I find it tiresome to worry about every little thing. My style is much more "deal with it when it's a problem" than "figure it out upfront."
In my long term dream, the castle, I live the life of a gentleman-artist. I dabble in whatever interests me. I continue to work hard and learn. But the things I want to build are zeppelins, submarines, secret passages, towers on islands in lakes, underwater fortresses, aquaponics, tropical greenhouses in the snow..
It's difficult to tie that kind of whimsical vision to a big company. I often experience seriousness as a one way street. It's easy to get more serious, hard to get less serious. It takes real discipline, optimism, and trust in order to maintain a fun, creative working culture where mistakes are celebrated. I think it's extremely difficult to have that environment at a big company, for reasons of human psychology**.
If I'm willing to accept that I have the mentality of an artist but the skills of an engineer, then it seems that software engineering at a big company isn't really for me. Developing little games is the closest thing I've found to being paid to do what I want. Making my own game seems like an inevitable path.
*I don't think it will stop being fun to work at Riot, more that it's gotten so difficult to push stuff live. When I arrived, associate engineers could push code live without any real process at all. I'm more comfortable in that kind of environment, even though it may not be appropriate for a product the size of LoL.
**monkeysphere.
so long,
suckers!*
I'm no longer at Riot. It was a good place to work and I really enjoyed many things about it, but ultimately my career is going in a different direction, and I'll have to figure that out.
I don't yet know what I'll be doing with my time, but Annie has her job and we have enough funds for the moment. Which means that all sorts of exciting possibilities are spread before us.
I'm really looking forward to figuring out what's next. Also if anyone want to talk about anything, hit me up. Real estate, stock, babies, restaurants, games, tech, cheese, whatever.
* "so long, suckers!" is a traditional farewell among my people. It carries no ill-will.
I'm no longer at Riot. It was a good place to work and I really enjoyed many things about it, but ultimately my career is going in a different direction, and I'll have to figure that out.
I don't yet know what I'll be doing with my time, but Annie has her job and we have enough funds for the moment. Which means that all sorts of exciting possibilities are spread before us.
I'm really looking forward to figuring out what's next. Also if anyone want to talk about anything, hit me up. Real estate, stock, babies, restaurants, games, tech, cheese, whatever.
* "so long, suckers!" is a traditional farewell among my people. It carries no ill-will.
dance of four elements
Yesterday I heard from my friend Luigi that he had joined a startup, http://www.terrajoulecorp.com/ this place (the website is down for me as of this writing but I expect it may be up again soon?) It's a really cool concept, which is to use a steam engine in combination with a solar hot water heater to solve a nagging problem in renewable energy - storage, consistency, and variable output.
The idea is that you can essentially store the solar energy captured by the concentrator as a (very) pressurized tank of (very) hot water. Then as needed, you bleed off some water into a lower pressure environment, which causes it to flash boil into steam. That steam drives an old-school piston steam engine, which generates electricity. The company is targeting community and industrial scale power generation with this, as essentially a replacement for auxiliary diesel generators, in places where those are regularly used.
The thing I love about this system is that it could have been built 100 years ago. It doesn't require any fancy chemistry or software. Well, maybe it does as delivered today, but the concept certainly seems like it would have been buildable 100 years ago, and would have generated a stable supply electricity from the sun.
My immediate scheme is to figure out how to scale it down far enough to work for the castle.
The other idea that this kicked off starts here:
http://www.etsy.com/listing/118749096/fire-and-water-ceramic-fountains?ref=related-4
So, the fire and water fountain is cool, but why does it need an external power source? That's lame. Why not combine it with something like this: google: candle turbine ?
Then you'd have three elements, fire, air, and water, you might as well work in the fourth. The idea that came to me was a stone water wheel that's driven by the candle turbine. So the candle drives the turbine, the turbine rotates the stone, which picks up water, maybe even just on its surface, as it rotates. I think it would be super cute.
Also would make an excellent puzzle door if scaled up, so that the stone wheel had a hole in it at some point, so you light the torches, wait for it to rotate... I guess you don't really need the water in that application but so what.
The idea is that you can essentially store the solar energy captured by the concentrator as a (very) pressurized tank of (very) hot water. Then as needed, you bleed off some water into a lower pressure environment, which causes it to flash boil into steam. That steam drives an old-school piston steam engine, which generates electricity. The company is targeting community and industrial scale power generation with this, as essentially a replacement for auxiliary diesel generators, in places where those are regularly used.
The thing I love about this system is that it could have been built 100 years ago. It doesn't require any fancy chemistry or software. Well, maybe it does as delivered today, but the concept certainly seems like it would have been buildable 100 years ago, and would have generated a stable supply electricity from the sun.
My immediate scheme is to figure out how to scale it down far enough to work for the castle.
The other idea that this kicked off starts here:
http://www.etsy.com/listing/118749096/fire-and-water-ceramic-fountains?ref=related-4
So, the fire and water fountain is cool, but why does it need an external power source? That's lame. Why not combine it with something like this: google: candle turbine ?
Then you'd have three elements, fire, air, and water, you might as well work in the fourth. The idea that came to me was a stone water wheel that's driven by the candle turbine. So the candle drives the turbine, the turbine rotates the stone, which picks up water, maybe even just on its surface, as it rotates. I think it would be super cute.
Also would make an excellent puzzle door if scaled up, so that the stone wheel had a hole in it at some point, so you light the torches, wait for it to rotate... I guess you don't really need the water in that application but so what.
mipmap my cubetexture and my nonsquare one too kthx
I'm using AGAL to learn about GPUs. It's pretty fun, but every new thing I try is several hours of, "oh, nothing is rendering. hm.."
It was not obvious to me (or documented) that Cube Textures in AGAL need to be uploaded with all mipmap levels.
It was also not obvious to me (or documented) that if you want any mipmapping, you need to upload all mipmap levels.
It was also not obvious to me (or documented) that if you have a non-sqaure texture, you still need to mipmap all the way down to 1x1.
Where should I go to learn stuff like this? Are there better places to start? Otherwise I will slowly de-noobify myself. But gosh golly this seems like basic stuff that should be in the API documentation.
The other side of it is, the tools for debugging stage3D are really pretty bad. So when something is not showing up, I can't debug into the shader or ask the gpu what it thinks, very easily. (maybe I should make some tools here.?) Instead I'm left to cobble together my own checklists like:
It was not obvious to me (or documented) that Cube Textures in AGAL need to be uploaded with all mipmap levels.
It was also not obvious to me (or documented) that if you want any mipmapping, you need to upload all mipmap levels.
It was also not obvious to me (or documented) that if you have a non-sqaure texture, you still need to mipmap all the way down to 1x1.
Where should I go to learn stuff like this? Are there better places to start? Otherwise I will slowly de-noobify myself. But gosh golly this seems like basic stuff that should be in the API documentation.
The other side of it is, the tools for debugging stage3D are really pretty bad. So when something is not showing up, I can't debug into the shader or ask the gpu what it thinks, very easily. (maybe I should make some tools here.?) Instead I'm left to cobble together my own checklists like:
- check your math
- short circuit to a known working texture/shader
- think harder
- add shader instructions back in to see if one of them mysteriously breaks something
- google related keywords
- try to think of a way to check intermediate/simpler results
- check your math
I don't mean to complain too much. I am having a good time. Half the time when nothing shows up it's because my math is wrong, and it's hard to get too upset* about that. But, if this is what it's like to be a graphics programmer, then, graphics programmers need some serious tool loving.
*But I'll try. Friggin mathematicians and their badly named variables. Effing half the variable names used in math are NON PRINTABLE CHARACTERS on a standard keyboard. why don't you call it Math.ratioOfCircumferenceToDiameter or something sensible like that. GAAH.
temperment
he felt a great restlessness inside of him
that compelled him to seek
and when he was still it would stir
like a stomach ache
that compelled him to seek
and when he was still it would stir
like a stomach ache
friggin linear algebra
I graduated from a prestigious university with an engineering degree. I work at one of the most exciting game companies in the world. But every time I try to do linear algebra, I become convinced that I'm just not smart enough.
screw you linear algebra. I don't need you. I have trigonometry and calculus, I can do just fine!
probably I need a better teacher.
screw you linear algebra. I don't need you. I have trigonometry and calculus, I can do just fine!
probably I need a better teacher.
routine, practice, and software engineering
Routine is healthy. Animals and children need it. It's good for adults too. It can be taken too far but by and large, a routine can be a good thing.
Practice is laudable. It makes you better at your craft. It's just what you do when you want to be good at something.
Software, oh software. Programming a computer is great because you write a thing once, and then THE COMPUTER DOES IT FOR YOU. You're done. You can check out. And the story of being a software engineer is the story of understanding problems, solving them in code once, and then letting the computer solve them from that point forward. If you never revisit your code, it might be because you did it right.
There's a disconnect here. As a programmer I'm attracted to the idea that I can solve a new problem every day, and accrue a mountain of functionality on which to perch, a labyrinth of routines and subroutines from which I need never venture. But if I ever succeeded, my very success would drive me mad from boredom. As a human animal I need the routine of solving problems. I need the practice to hone my skill. But my very success sabotages my own mental health. At large scale, it is a delicious psychological vignette.
Practice is laudable. It makes you better at your craft. It's just what you do when you want to be good at something.
Software, oh software. Programming a computer is great because you write a thing once, and then THE COMPUTER DOES IT FOR YOU. You're done. You can check out. And the story of being a software engineer is the story of understanding problems, solving them in code once, and then letting the computer solve them from that point forward. If you never revisit your code, it might be because you did it right.
There's a disconnect here. As a programmer I'm attracted to the idea that I can solve a new problem every day, and accrue a mountain of functionality on which to perch, a labyrinth of routines and subroutines from which I need never venture. But if I ever succeeded, my very success would drive me mad from boredom. As a human animal I need the routine of solving problems. I need the practice to hone my skill. But my very success sabotages my own mental health. At large scale, it is a delicious psychological vignette.
dry
I like my martinis like I like my humor, like I like my application code:
DRY.
http://c2.com/cgi/wiki?DontRepeatYourself
but not too dry.
I read the gang of four design patterns book a while ago and I've been thinking about it a bit. Aside from the patterns, which are whatever, the actual premise of the book is really interesting, which is that these patterns come up again and again and again in software development.
That's difficult to reconcile with the DRY principle, or at least it admits defeat. It says, you will write this many times, so at least write it the same way each time, ok?
This is a little bit what I was trying to get at in the previous post; code reuse is a ruse. It almost never happens in the real world, at least not the way we want it to. As a programmer, I am chasing this fantasy that I will write a thing once, and then it will be Written, and I may Reuse it for the rest of my life.
But the fact is, code is actually easier to write than it is to read. So, six months from now when I've forgotten al the details of what I just wrote, I will happier to write it again than to try to understand what I wrote previously. Sad but true.
Taking that conclusion and applying it back to the DRY principle is interesting. It suggests limits on how seriously we should take the principle. I am actually a huge believer in DRY as a heuristic for class and module design. At a code level it makes a ton of sense. But over time, and over large teams, it breaks down. It may be worth repeating yourself, in order to avoid the hassle of creating a dependency. It may be worth repeating yourself, in order to create a new local version of the same knowledge. As broken as that sounds.
The result of making this compromise consciously is something in between code and data. "Script" is the closest word for it. I've been thinking a lot about the continuum of art-design-code-system-hardware, and it's interesting to me how different people gravitate to different points on the scale.
The people who live over on the right have a bad attitude, in my opinion, towards anyone to the left of them. I get to say that because I could be one of them, if I wanted to. So I tell myself.
DRY.
http://c2.com/cgi/wiki?DontRepeatYourself
but not too dry.
I read the gang of four design patterns book a while ago and I've been thinking about it a bit. Aside from the patterns, which are whatever, the actual premise of the book is really interesting, which is that these patterns come up again and again and again in software development.
That's difficult to reconcile with the DRY principle, or at least it admits defeat. It says, you will write this many times, so at least write it the same way each time, ok?
This is a little bit what I was trying to get at in the previous post; code reuse is a ruse. It almost never happens in the real world, at least not the way we want it to. As a programmer, I am chasing this fantasy that I will write a thing once, and then it will be Written, and I may Reuse it for the rest of my life.
But the fact is, code is actually easier to write than it is to read. So, six months from now when I've forgotten al the details of what I just wrote, I will happier to write it again than to try to understand what I wrote previously. Sad but true.
Taking that conclusion and applying it back to the DRY principle is interesting. It suggests limits on how seriously we should take the principle. I am actually a huge believer in DRY as a heuristic for class and module design. At a code level it makes a ton of sense. But over time, and over large teams, it breaks down. It may be worth repeating yourself, in order to avoid the hassle of creating a dependency. It may be worth repeating yourself, in order to create a new local version of the same knowledge. As broken as that sounds.
The result of making this compromise consciously is something in between code and data. "Script" is the closest word for it. I've been thinking a lot about the continuum of art-design-code-system-hardware, and it's interesting to me how different people gravitate to different points on the scale.
The people who live over on the right have a bad attitude, in my opinion, towards anyone to the left of them. I get to say that because I could be one of them, if I wanted to. So I tell myself.
programmer psychoses, better code
We deal in the abstract; it's in the job description. Think about the word "code" for a while.
Runaway abstraction is an occupational hazard. You can find lists of software design principles, and coding principles, laws, rules, etc., that are all aimed at giving programmers heuristics for writing "better code." As an occupational programmer, it is really really easy to start to believe in these heuristics.
But hey, sometimes a scripting language is the right tool for the job.
Sometimes there is no clear line between code and data.
Sometimes a hack is the right answer.
Sometimes an abstraction layer is a mistake, and sometimes it's a critical improvement.
In doing code reviews, especially for external teams / contractors, I'm in a curious position where I may choose to impose my heuristics on other people's code.
Each defect I log is a minor crisis of conscience, where I pass judgement, create work, and reject another professional's opinion. So I must weigh that cost against my belief that I am driving them to "better code."
The decisions are necessary and I make them quickly, most of the time. It's an interesting journey.
Runaway abstraction is an occupational hazard. You can find lists of software design principles, and coding principles, laws, rules, etc., that are all aimed at giving programmers heuristics for writing "better code." As an occupational programmer, it is really really easy to start to believe in these heuristics.
But hey, sometimes a scripting language is the right tool for the job.
Sometimes there is no clear line between code and data.
Sometimes a hack is the right answer.
Sometimes an abstraction layer is a mistake, and sometimes it's a critical improvement.
In doing code reviews, especially for external teams / contractors, I'm in a curious position where I may choose to impose my heuristics on other people's code.
Each defect I log is a minor crisis of conscience, where I pass judgement, create work, and reject another professional's opinion. So I must weigh that cost against my belief that I am driving them to "better code."
The decisions are necessary and I make them quickly, most of the time. It's an interesting journey.
software rant
Alright, nobody is going to care about this, but I am a usability zealot, so I'm going to tell you anyway.
http://www.johndcook.com/blog/2011/12/30/advantages-of-everything-is-text/
I read this post about Emacs (don't get me started please) and some of the features he describes made me realize how low our standards are for usability of a command line interface.
Much in the same way that Microsoft hasn't fundamentally improved MS Paint since well, ever, it is my perception that command line interfaces haven't significantly improved since well, Unix.
I might be wrong, I am not a CLI guy. But here's what I keep looking for that I don't find:
I work primarily in Windows, and I've been looking for a DOS prompt replacement that gives me any of this, and I've always been very underwhelmed. It's like getting excited about the next version of windows because you think MS Paint might suck less. Eternal disappointment.
I can see that a lot of what I'm asking for is what Emacs seems to provide, which is basically that your commands are editable in a sane and modern way. Does anyone actually use this feature? And, am I alone? Does the Linux CLI suck just as bad as the Windows prompt? Or am I asking for things that I can never have for some (historical, bad) reason?
Stuff like this really makes me question my own sanity, because the gaping lack of quality tears at my face every time I use these tools, but the people who use and advocate this stuff don't seem to notice it. Perhaps they know tricks I don't, but I think they've just gotten really good at MS Paint.
Also to the point of the article, the big win is not so much that everything is text. It's that somebody paid attention to how the tool is actually used, and put some effort and imagination into it.
http://www.johndcook.com/blog/2011/12/30/advantages-of-everything-is-text/
I read this post about Emacs (don't get me started please) and some of the features he describes made me realize how low our standards are for usability of a command line interface.
Much in the same way that Microsoft hasn't fundamentally improved MS Paint since well, ever, it is my perception that command line interfaces haven't significantly improved since well, Unix.
I might be wrong, I am not a CLI guy. But here's what I keep looking for that I don't find:
- resize the window with my mouse and have that be meaningful (change the number of columns interactively)
- select, copy, paste text with common mouse and keyboard commands
- autocomplete, intellisense
- persistent command memory (across sessions)
- directory awareness, content visibility
- application awareness (ant, maven plugins that autocomplete targets, projects, etc.)
- hey, tabs?
- unlimited or very large buffer (like a txt file in an editor. You delete history when I tell you to, stupid computer.)
- saving sessions and/or making results accessible as text files
- text folding so I can hide verbose output
I work primarily in Windows, and I've been looking for a DOS prompt replacement that gives me any of this, and I've always been very underwhelmed. It's like getting excited about the next version of windows because you think MS Paint might suck less. Eternal disappointment.
I can see that a lot of what I'm asking for is what Emacs seems to provide, which is basically that your commands are editable in a sane and modern way. Does anyone actually use this feature? And, am I alone? Does the Linux CLI suck just as bad as the Windows prompt? Or am I asking for things that I can never have for some (historical, bad) reason?
Stuff like this really makes me question my own sanity, because the gaping lack of quality tears at my face every time I use these tools, but the people who use and advocate this stuff don't seem to notice it. Perhaps they know tricks I don't, but I think they've just gotten really good at MS Paint.
Also to the point of the article, the big win is not so much that everything is text. It's that somebody paid attention to how the tool is actually used, and put some effort and imagination into it.
you tell me
Today I wrote my first self-motivated FlexUnit tests to test my as3 quaternion utilities. At my laptop in our rented condo in Kauai. While my wife is out snorkeling on the beach 100 yards away.
...
but the baby physics engine* is looking pretty good, I've got angular joints working now (though they don't handle torsion? I think that's a separate joint?) and stick joints look pretty good too, and I built a little inspector panel with tabs so that I can easily tweak stuff. And the math is all in 3D, which is a bit of a leap for me (much more thinking... such a pain.)
Unit testing is still a little unfamiliar to me I must admit, but I'm enjoying the added confidence it gives me about the math I'm using. Now it might be time to work on plant biology and rendering, which is after all what I sat down to do in the first place before I got distracted by all this 3d math.
Or, it might be time to head over to the beach I guess.
*Annie likes to call it a "baby-physics engine" instead of a "baby physics-engine." I like the mental image. :-)
...
but the baby physics engine* is looking pretty good, I've got angular joints working now (though they don't handle torsion? I think that's a separate joint?) and stick joints look pretty good too, and I built a little inspector panel with tabs so that I can easily tweak stuff. And the math is all in 3D, which is a bit of a leap for me (much more thinking... such a pain.)
Unit testing is still a little unfamiliar to me I must admit, but I'm enjoying the added confidence it gives me about the math I'm using. Now it might be time to work on plant biology and rendering, which is after all what I sat down to do in the first place before I got distracted by all this 3d math.
Or, it might be time to head over to the beach I guess.
*Annie likes to call it a "baby-physics engine" instead of a "baby physics-engine." I like the mental image. :-)
in kauai*
Some places are a letdown. They don't live up to the hype and the advertising, you get there and you think, oh, that's nice I guess. I was sorta expecting more.
Kauai is not one of those places though. Neither is the the Grand Canyon (actually grand). But yeah Hawaii in general is a little mind-blowing.
We were walking through the grounds of a hotel down the coast from where we're staying (in a condo cause it's cheaper and way better) and I got to thinking about how posh hotels terrify me.
Not as a guest. They terrify me from business perspective. It's such an amazing risk, to take, what, tens of millions of dollars and sink it into building a resort on some piece of coast near a natural wonder, with the confidence that you can earn it all back and change, in what, 5 years, 10 years, what? And all of the tens of thousands of details that go into it.
Anyway the magnitude of the business venture staggers me a little, and it makes me a little queasy to be a place like that, because it puts me in mind of the kind of people that could pull that off. I know I guess that they're just people on some level, but on another more childish level I suspect them of being well basically, cold calculating psychopaths, to be able to risk that much.
Which goes to show that I am still a small town boy, fresh off the farm, etc.. I have relatively small ambitions on that scale. Build a castle. Doesn't sound so hard.
Also I'm having a good time working on a grass growing sim in my down time. :-) I'll post the results if there are any.
*we got married!!! it was great. pictures may show up at some point.
Kauai is not one of those places though. Neither is the the Grand Canyon (actually grand). But yeah Hawaii in general is a little mind-blowing.
We were walking through the grounds of a hotel down the coast from where we're staying (in a condo cause it's cheaper and way better) and I got to thinking about how posh hotels terrify me.
Not as a guest. They terrify me from business perspective. It's such an amazing risk, to take, what, tens of millions of dollars and sink it into building a resort on some piece of coast near a natural wonder, with the confidence that you can earn it all back and change, in what, 5 years, 10 years, what? And all of the tens of thousands of details that go into it.
Anyway the magnitude of the business venture staggers me a little, and it makes me a little queasy to be a place like that, because it puts me in mind of the kind of people that could pull that off. I know I guess that they're just people on some level, but on another more childish level I suspect them of being well basically, cold calculating psychopaths, to be able to risk that much.
Which goes to show that I am still a small town boy, fresh off the farm, etc.. I have relatively small ambitions on that scale. Build a castle. Doesn't sound so hard.
Also I'm having a good time working on a grass growing sim in my down time. :-) I'll post the results if there are any.
*we got married!!! it was great. pictures may show up at some point.
not a great sign
Is it bad that I'm excited that I might be getting sick, because I'll finally be able to get some work done?
my profession
I talked to a guy on the phone today, who wants to work at my company. Smart guy. I asked him a bunch of tricky questions, and from this I surmised that he'd be likely to survive an onsite interview. That's great. That's what you want out of every phone screen.
It got me thinking about my profession. A lot of what makes me good at my job is incredibly arbitrary, like knowing what connects to what, and who worked on that. But then again a lot of it is what you might call "intrinsic." I like finding out how stuff works. I like solving hard problems. I hate admitting defeat. I enjoy finding workarounds. That sort of thing.
But there's another category of traits that is in-between. I understand when to comment my methods and when to move on. I have a feeling for what to name my classes and variables. I have a good hunch for when a breakpoint will tell me something, and when a file search will help. Sometimes I can just type out a class or three. I guess this space in the middle is what I call "software engineering." I place a value on this stuff, which is independent of the value that I place on seniority, and different from the value I place on ability.
Maybe it's simply because I realize, the older get and the more I move around, the less I can rely on ability OR seniority to govern my salary. It's in my interest to promote the value of professionalism at this point in my career.
;-)
It got me thinking about my profession. A lot of what makes me good at my job is incredibly arbitrary, like knowing what connects to what, and who worked on that. But then again a lot of it is what you might call "intrinsic." I like finding out how stuff works. I like solving hard problems. I hate admitting defeat. I enjoy finding workarounds. That sort of thing.
But there's another category of traits that is in-between. I understand when to comment my methods and when to move on. I have a feeling for what to name my classes and variables. I have a good hunch for when a breakpoint will tell me something, and when a file search will help. Sometimes I can just type out a class or three. I guess this space in the middle is what I call "software engineering." I place a value on this stuff, which is independent of the value that I place on seniority, and different from the value I place on ability.
Maybe it's simply because I realize, the older get and the more I move around, the less I can rely on ability OR seniority to govern my salary. It's in my interest to promote the value of professionalism at this point in my career.
;-)
hawthorne real estate report
I saw this place while walking back from the hardware store with some lamp parts.
It's a cute little two house setup very similar to ours. Nice and private in the back. The houses look like they're in decent shape though they probably need new windows and the yard needs a ton of love.
Anyway it made me hungry. After the wedding and a couple other financial milestones are reached, I want to start working on a down payment for something like this... The business makes too much sense.
If you're looking for an investment property in Los Angeles and you aren't brave enough for Boyle Heights, you should consider Hawthorne.
It's a cute little two house setup very similar to ours. Nice and private in the back. The houses look like they're in decent shape though they probably need new windows and the yard needs a ton of love.
Anyway it made me hungry. After the wedding and a couple other financial milestones are reached, I want to start working on a down payment for something like this... The business makes too much sense.
If you're looking for an investment property in Los Angeles and you aren't brave enough for Boyle Heights, you should consider Hawthorne.
sup
I've been thinking about the BuildGrow thing a lot lately. Isaac has some really good ideas for a generated Crystalis-style game, which I think would be super cool. So I started back in on the socket server. I got login working and I'm happy with my amf serialization layer. I don't know if I need to add compression to it as well. I might have to I guess depending on how the game ends up shaking out.
At work I've been doing a lot of advocacy lately, which is a new role for me. But as our little corner of the business is starting to look like it's in pretty good shape, I'm able to pull my head out of the code for long enough to notice that there are other departments, too. So some of this socket server stuff I'm working on at home is a way of limbering up to tackle the broader challenges at work, I guess.
Sigh. I think about work a lot but, I can't really write about it too much here, because a lot of the stuff I want to talk about it not public knowledge. That's frustrating but I love my job too much to risk it. ;-)
The other thing about this BuildGrow stuff, is that it's a great way of procrastinating. What I should be working on right now is wedding stuff. <_< That stuff is mostly under control I guess. I feel really good about the plans we do have, at least. It's the ones we don't have that are starting to be a concern. I guess we should figure out a honeymoon pretty soon here...
Also my diet is going pretty well. I have about 7 pounds to drop to reach my long-term goal, which is to be 185 at our wedding. I think I will make it. Then after the honeymoon I'll have to work on getting back down to it. Then I'll reevaluate.
There's a lot of crunchy minecrafty, dwarf-fortressy stuff on my mind these days, and a lot of wedding and adulthood stuff too, but I want to break all that out into separate posts.
At work I've been doing a lot of advocacy lately, which is a new role for me. But as our little corner of the business is starting to look like it's in pretty good shape, I'm able to pull my head out of the code for long enough to notice that there are other departments, too. So some of this socket server stuff I'm working on at home is a way of limbering up to tackle the broader challenges at work, I guess.
Sigh. I think about work a lot but, I can't really write about it too much here, because a lot of the stuff I want to talk about it not public knowledge. That's frustrating but I love my job too much to risk it. ;-)
The other thing about this BuildGrow stuff, is that it's a great way of procrastinating. What I should be working on right now is wedding stuff. <_< That stuff is mostly under control I guess. I feel really good about the plans we do have, at least. It's the ones we don't have that are starting to be a concern. I guess we should figure out a honeymoon pretty soon here...
Also my diet is going pretty well. I have about 7 pounds to drop to reach my long-term goal, which is to be 185 at our wedding. I think I will make it. Then after the honeymoon I'll have to work on getting back down to it. Then I'll reevaluate.
There's a lot of crunchy minecrafty, dwarf-fortressy stuff on my mind these days, and a lot of wedding and adulthood stuff too, but I want to break all that out into separate posts.
Subscribe to:
Posts (Atom)