"...It's in our DNA"
Gaaahh. I *HATE* when corporations use that phrase.
It's not in your DNA, even metaphorically. If it were, you would not have to keep apologizing for security breaches, or for crappy customer service, etc., etc., etc.
It's just some uneducated marketing hack who wants it to sound like they can't fail.
Nearly as bad is "laser-focused". 'Cause the whole point of a laser is that it is not focused, it's collimated. If you focused it, it would no longer be a laser, and no longer any use.
Monday, November 21, 2016
Sunday, November 20, 2016
Juggling a few too many things
At The New Job, the product I'm supporting is a good example of how a small skilled team can do amazing things. It's going strong after 3 years when it was supposed to be a stop-gap lasting only 6 months.
But in the course of my learning the ropes, I've run into a situation that allowed me to finally put into words something that I've felt for a long time about systems design - simplicity of all things is a virtue.
The setup - the product is a collection of scripts and binaries that process incoming files. There are bash scripts, Python scripts, Ruby scripts, C binaries, cron jobs, and even a Java binary. The upshot of this is that it requires a fairly experienced developer to be able to work on the system as a whole. Now, this can be an issue in finding suitable developers, but it's not a high hurdle. But where it does cause a problem is that the corporate sysadmin environment is very controlled, and it is not a simple thing to get tools installed, and the more tools you use, the worse it gets.
So, I'm having to navigate the labyrinth of corporate IT to get the desired versions of Python and Ruby approved and installed on our production systems, as well as the boilerplate necessities of user accounts.
Moral of the story - consider the overall ease of use when choosing languages to build a system in
But in the course of my learning the ropes, I've run into a situation that allowed me to finally put into words something that I've felt for a long time about systems design - simplicity of all things is a virtue.
The setup - the product is a collection of scripts and binaries that process incoming files. There are bash scripts, Python scripts, Ruby scripts, C binaries, cron jobs, and even a Java binary. The upshot of this is that it requires a fairly experienced developer to be able to work on the system as a whole. Now, this can be an issue in finding suitable developers, but it's not a high hurdle. But where it does cause a problem is that the corporate sysadmin environment is very controlled, and it is not a simple thing to get tools installed, and the more tools you use, the worse it gets.
So, I'm having to navigate the labyrinth of corporate IT to get the desired versions of Python and Ruby approved and installed on our production systems, as well as the boilerplate necessities of user accounts.
Moral of the story - consider the overall ease of use when choosing languages to build a system in
Saturday, July 30, 2016
Movin' On Up
Well, Dear Readers, you can rest easy - I am gainfully employed (as of the middle of May, actually)
I moved to a small group in a large corporation, with all the chaos that implies. I"m also working a project that an old friend started, so I have a bit of a narrow ledge to walk, not wanting to disparage work that is provably profitable.
I will not, however, spare the company. They can take it.
The big thing in my immediate headlights is the weird corporate labyrinth of permissions, requests, and partitioning of tasks. It seems to take 6 different groups to get anything done.
I moved to a small group in a large corporation, with all the chaos that implies. I"m also working a project that an old friend started, so I have a bit of a narrow ledge to walk, not wanting to disparage work that is provably profitable.
I will not, however, spare the company. They can take it.
The big thing in my immediate headlights is the weird corporate labyrinth of permissions, requests, and partitioning of tasks. It seems to take 6 different groups to get anything done.
Sunday, June 19, 2016
Gambling with your future
I ran across this article about where new CS grads are going, and was somewhat disturbed by the 'advice' being given by Paul Graham, and someone named Harj Taggar. They push the idea that new grads should not be looking to work for the established companies, but instead should be looking to work for companies that will be "the next big thing". They hold out a number of (probably made-up) statistics comparing overall earnings (Going with a known company gets you a 90% chance for $1.1 million, while the new thing gets you 10% chance for $10 million).
Now, Paul Graham has a history of success, but I think he's being disengenuous here in claiming that a new grad has a 10% chance of selecting the next big thing (NBT) at a point where they will get the big payoff. VCs are much more predatory these days, locking up preferential stock so that they get their money back before any of the engineers get a payout, so even if you were able to find the NBT and get hired, you might not get anything more than a few years' worth of income from it. He also seems to be forgetting that there were so many new things back in the late 90's that it was very hard to pick the winners. Graham picked Google, but it was in no way a sure thing at that time. I'm sure the engineers at WebVan thought well of their chances of becoming millionaires.
Finally, there is the issue of basic compensation. Startups generally cannot pay as well as established companies, and often have much lower benefits, which makes working for a startup in Silicon Valley much less viable, given the cost of living out there. Seattle is similar; likewise NYC.
(PS. A conspiracy-theory view is that VCs want to keep the supply of engineers working at startups high, to keep salaries lower (you can pay less, offer more stock options that may not vest fully, etc) so that there are enough startups for the VCs to hit their percentages for success)
Now, Paul Graham has a history of success, but I think he's being disengenuous here in claiming that a new grad has a 10% chance of selecting the next big thing (NBT) at a point where they will get the big payoff. VCs are much more predatory these days, locking up preferential stock so that they get their money back before any of the engineers get a payout, so even if you were able to find the NBT and get hired, you might not get anything more than a few years' worth of income from it. He also seems to be forgetting that there were so many new things back in the late 90's that it was very hard to pick the winners. Graham picked Google, but it was in no way a sure thing at that time. I'm sure the engineers at WebVan thought well of their chances of becoming millionaires.
Finally, there is the issue of basic compensation. Startups generally cannot pay as well as established companies, and often have much lower benefits, which makes working for a startup in Silicon Valley much less viable, given the cost of living out there. Seattle is similar; likewise NYC.
(PS. A conspiracy-theory view is that VCs want to keep the supply of engineers working at startups high, to keep salaries lower (you can pay less, offer more stock options that may not vest fully, etc) so that there are enough startups for the VCs to hit their percentages for success)
Sunday, May 15, 2016
Ch-ch-ch-changes. Turn and face the strange.....
(With apologies to David Bowie)
Whew.
It's been a busy time these past few months.
Let me explain.
No, there is too much; let me sum up.
The Job decided that the profit margin on the project I was part of was not high enough to suit the career aspirations of the C-level acolytes in charge of the business unit, so it was dropped, along with 90% of the team. So I found myself in good company as I started to look for a new job in earnest. Fortunately, the severance package was nice, so I was not left hurting. Still, the sudden but inevitable betrayal was not a fun time.
The biggest problem I had was exactly what I had complained to my then boss 5 years ago when they started splitting the group up - my continued presence in the 'maintain the old application' subgroup meant that I was not learning new skills. "Don't worry," I was told, "We will rotate other people in as their parts deploy, and you will get to learn new stuff."
And the check is in the mail......
The moral of this fable is that you never trust the organization to honor any offhand statement - if they say they will do X, set up a monthly reminder to ask them about X, until they do it, or you get something else of equal worth, or you do X on your own. If they haven't delivered within a year, assume they will not ever, and do it yourself.
Especially when it comes to 'rotating' work assignments - it's way too easy for the folks who are working on the new stuff to take longer than planned (intentionally or otherwise), and for management to feel that they do not know the current set of issues in your area of control, and keep you where you are "just until things settle", which may never happen.
Another bit of advice is to look for a new job every quarter, minimum. You don't ever have to take one if it gets offered, but it keeps you in practice for interviews, keeps your resume up-to-date, and lets you know what the market for your skills is.
Oh, and one little trick if you are looking for a job and are on LinkedIn - search for and visit the profiles of every recruiter in areas you are looking for (tech sectors and geography); when they look at the activity on their profile, they will see your visit, and get curious about you, and visit you in return, where your profile should be able to grab their attention.
Whew.
It's been a busy time these past few months.
Let me explain.
No, there is too much; let me sum up.
The Job decided that the profit margin on the project I was part of was not high enough to suit the career aspirations of the C-level acolytes in charge of the business unit, so it was dropped, along with 90% of the team. So I found myself in good company as I started to look for a new job in earnest. Fortunately, the severance package was nice, so I was not left hurting. Still, the sudden but inevitable betrayal was not a fun time.
The biggest problem I had was exactly what I had complained to my then boss 5 years ago when they started splitting the group up - my continued presence in the 'maintain the old application' subgroup meant that I was not learning new skills. "Don't worry," I was told, "We will rotate other people in as their parts deploy, and you will get to learn new stuff."
And the check is in the mail......
The moral of this fable is that you never trust the organization to honor any offhand statement - if they say they will do X, set up a monthly reminder to ask them about X, until they do it, or you get something else of equal worth, or you do X on your own. If they haven't delivered within a year, assume they will not ever, and do it yourself.
Especially when it comes to 'rotating' work assignments - it's way too easy for the folks who are working on the new stuff to take longer than planned (intentionally or otherwise), and for management to feel that they do not know the current set of issues in your area of control, and keep you where you are "just until things settle", which may never happen.
Another bit of advice is to look for a new job every quarter, minimum. You don't ever have to take one if it gets offered, but it keeps you in practice for interviews, keeps your resume up-to-date, and lets you know what the market for your skills is.
Oh, and one little trick if you are looking for a job and are on LinkedIn - search for and visit the profiles of every recruiter in areas you are looking for (tech sectors and geography); when they look at the activity on their profile, they will see your visit, and get curious about you, and visit you in return, where your profile should be able to grab their attention.
Sunday, January 10, 2016
Today's Agile WTF?
Ok, so I've noted that as your organization moves to an Agile development methodology, it will face many hazards.
Today's example - managerial misunderstanding of Agile teams
At The Job, we have a number of offshore development groups, and a few domestic groups. Due to the skill mix needed, we've split into a number of scrum teams that consist of developers on both sides of the ocean. Note that this is already contrary to the spirit of Agile, which strongly recommends a team be located in one location, but it's a common reality in many organizations, where the skills are not equally distributed.
Where we see the real WTF moment is when the offshore management decided that the scrum team split did not work with their existing managerial tree, and they peopled the scrum teams with partial developers: people who are allocated part-time to multiple teams, so that no manager 'loses' people to scrum teams. This leads to problems because a given developer can be unavailable to a team if another team has a problem that runs long and the priorities favor the other team. Which translates to a problem in one scrum team bleeds into 1 or more other teams.
Now, there are times when a specialist is needed only some of the time for various teams; DBAs are commonly like this; once the DB is in place, the DBA is only needed for a short time for new tables or indices.
But this is full-time, 10s of developers split among 2, 3, or more teams, leading to cascading delays.
So heed this warning! Let your devs work on one team!
Today's example - managerial misunderstanding of Agile teams
At The Job, we have a number of offshore development groups, and a few domestic groups. Due to the skill mix needed, we've split into a number of scrum teams that consist of developers on both sides of the ocean. Note that this is already contrary to the spirit of Agile, which strongly recommends a team be located in one location, but it's a common reality in many organizations, where the skills are not equally distributed.
Where we see the real WTF moment is when the offshore management decided that the scrum team split did not work with their existing managerial tree, and they peopled the scrum teams with partial developers: people who are allocated part-time to multiple teams, so that no manager 'loses' people to scrum teams. This leads to problems because a given developer can be unavailable to a team if another team has a problem that runs long and the priorities favor the other team. Which translates to a problem in one scrum team bleeds into 1 or more other teams.
Now, there are times when a specialist is needed only some of the time for various teams; DBAs are commonly like this; once the DB is in place, the DBA is only needed for a short time for new tables or indices.
But this is full-time, 10s of developers split among 2, 3, or more teams, leading to cascading delays.
So heed this warning! Let your devs work on one team!
Friday, January 08, 2016
What's Up, Docs?
Ok, it's taken a few incidents, but I've just got to vent about the state of developer documentation at The Job.
We have, like many places, a wiki for the devs to store documentation about our systems, tools, plans, etc. It's the usual jungle of outdated posts, incomplete references, and even chat transcripts, but the detail that got me today is the abysmal quality of several pages pages - one was the description of a library API, the other was the steps to set up a VM for testing.
The API had a list of the methods for a Java class, but the list was an image capture of a scrollbarred list - not a image in a window with scrollbars, but the static image of the list. So not only was it lazy, it was nearly useless, in that it was neither a set of linkable items, nor text that I could copy to paste into another search.
The directions page was rife with assumptions of context - that I knew what parts of the images pasted into the list referred to, again without giving me text that I could cut&paste for ease of following or modifying. I mean, I'm not necessarily the sharpest guy, but the entire point of the list of directions is to make it clear what to do, even for someone who is unfamiliar with the task.
Please, please, people, if you are writing developer documentation, make it easy for the reader to use your steps, and make sure you give full context.
We have, like many places, a wiki for the devs to store documentation about our systems, tools, plans, etc. It's the usual jungle of outdated posts, incomplete references, and even chat transcripts, but the detail that got me today is the abysmal quality of several pages pages - one was the description of a library API, the other was the steps to set up a VM for testing.
The API had a list of the methods for a Java class, but the list was an image capture of a scrollbarred list - not a image in a window with scrollbars, but the static image of the list. So not only was it lazy, it was nearly useless, in that it was neither a set of linkable items, nor text that I could copy to paste into another search.
The directions page was rife with assumptions of context - that I knew what parts of the images pasted into the list referred to, again without giving me text that I could cut&paste for ease of following or modifying. I mean, I'm not necessarily the sharpest guy, but the entire point of the list of directions is to make it clear what to do, even for someone who is unfamiliar with the task.
Please, please, people, if you are writing developer documentation, make it easy for the reader to use your steps, and make sure you give full context.
Subscribe to:
Posts (Atom)