local PDX startup looking for Rails developer
km
John Wilger
> views developing software as an craft rather then a profession.
Serious question, not snark: do you (or anyone else here) view craftsmanship and professionalism as being in opposition to each other? That's how I interpret that statement, but maybe that's not what you meant.
For the record, I do not view them as being in opposition. I see them as two circles on a Venn diagram where the ideal developer falls in the overlapping bit.
--
Regards,
John Wilger
Kerri Miller
--
You received this message because you are subscribed to the Google Groups "pdxruby" group.
To post to this group, send email to pdx...@googlegroups.com.
To unsubscribe from this group, send email to pdxruby+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdxruby?hl=en.
Sam Livingston-Gray
> On Apr 23, 2012, at 2:04 PM, km wrote:
>> views developing software as an craft rather then a profession.
>
> Serious question, not snark: do you (or anyone else here) view craftsmanship and professionalism as being in opposition to each other? That's how I interpret that statement, but maybe that's not what you meant.
>
> For the record, I do not view them as being in opposition. I see them as two circles on a Venn diagram where the ideal developer falls in the overlapping bit.
Likewise. To me, the primary mark of a profession is some sort of
institutional barrier to entry -- e.g., a legal bar association, a
medical board, or an engineering certification process. I would
*hope* that professional organizations also encourage their members to
improve their craft over time, but organizations tend to develop their
own objectives. ;>
Sam Livingston-Gray
> PS - did we set up a separate snark backchannel yet? :)
John Wilger
Although the answer was, itself, a failure to use it. :-P
Adron Hall
--
You received this message because you are subscribed to the Google Groups "pdxruby" group.
To post to this group, send email to pdx...@googlegroups.com.
To unsubscribe from this group, send email to pdxruby+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdxruby?hl=en.
John Wilger
> I read the original email as looking for craftspeople rather than jobbers -- software development/engineering as a calling rather than a paycheck. OP, correct as you like.
That's definitely how I was hoping I could read it. It's the use of "profession" rather than simply "job" that makes me unsure.
At any rate, I have no reason to suspect there's anything wrong with this job, I just thought it was an interesting choice of words. This is exactly the kind of posting I'd like to see on this list, so I hope that km is able to get a good response!
Phillip Kerman
craftsman, if you don't have a profitable business then you can't be a
craftsman for long. I suppose you could just do it as a hobby--but as much
as I like programming, I always think of what I am doing as providing value
to a client.
Brad Heller
John Wilger
> Are there any organizations that actually advertise for "jobbers?" For that matter, what percentage of the dev world considers themselves "craftspeople?"
>
> My bet: Not many, and quite a few :)
I think you're selecting for the crowd you run with (indicated by your participation here.) :-)
Unfortunately, while not many companies would advertise for it like that, there are many where it is the case (particularly in overseas outsourcing) and there are many folks who just do what they have to to get paid.
Reid Beels
Are there any organizations that actually advertise for "jobbers?"
Phillip Kerman
First, I usually find craigslist ads depressing—but what about that job sounds like a ‘jobber’ (whatever that is)? Just asking.
From this discussion I still can’t see what the difference is.
Thanks,
Phillip
--
John Wilger
> First, I usually find craigslist ads depressing—but what about that job sounds like a ‘jobber’ (whatever that is)? Just asking.
>
> From this discussion I still can’t see what the difference is.
I'm not sure about the craigslist posting that Reid points to, but a "jobber" is someone who doesn't intrinsically care about doing the best they can do in their chosen profession; they are only motivated by extrinsic rewards (salary, etc.) and will only put as much effort into their work as they need to in order to earn that reward.
A "craftsperson" *, on the other hand, is intrinsically motivated to become better at their craft and to produce the highest quality work that they can. They are more likely to leave an employer due to that employer not valuing quality production than they are over pay (although, in our industry, adequate pay is rarely an issue for this person.)
* My biggest problem with "craftsman"/"craftsmanship" is the gender bias.
Phillip Kerman
to "care" or do the best POSSIBLE then you're neither a good craftsperson or
employee. On the other hand, there's such a thing as wanting to do the best
regardless of cost. I've seen this cause projects to fail--all these well
intentioned folks not able to let things go in order to just get something
done.
I guess I don't really see how someone can't be a little of both. I recall
hearing/reading Tina Fey saying a big problem with many creative people is
being "too creative". Not knowing how to just get something done for the
sake of completing it.
John Wilger
On Apr 23, 2012, at 4:38 PM, Phillip Kerman wrote:
> Cool--I think I get the definition. My take, however, is if you're not going
> to "care" or do the best POSSIBLE then you're neither a good craftsperson or
> employee.
I agree with that. I think the problem is that some companies end up with a Dead Sea Effect, so the people responsible for evaluating employees are also "jobbers". You will run into this way more at big, public corporations than you will in a startup where dead weight is much more noticeable in the bottom line.
> On the other hand, there's such a thing as wanting to do the best
> regardless of cost. I've seen this cause projects to fail--all these well
> intentioned folks not able to let things go in order to just get something
> done.
I agree,
> I guess I don't really see how someone can't be a little of both. I recall
> hearing/reading Tina Fey saying a big problem with many creative people is
> being "too creative". Not knowing how to just get something done for the
> sake of completing it.
I agree with that. There's a tendency with creative types to…well…create. Good software developers are, in my experience, creative types. That's why you need the discipline of your craft to help you know the difference between work that needs to be done in order to have an acceptable product and work that you're doing just to stroke your own creative desires.
However, it is *never* wasteful to write well-factored code and stick to other good practices and techniques. These will *always* make you go faster in both the long run *and* the short run. Good technique has *never* been the thing that was responsible for a failed project. It's lack of discipline that kills software projects, not good code.
This issue is *solved* by being adept at your craft, because part if that is being able to understand the context in which you are working so as not to waste your customer's money and time.
If I hire a carpenter to build storage shelves in my garage, I expect them to build to the highest standard of carpentry. I want to end up with shelves that will hold all my stuff without collapsing, and I want them to be just as good in fifty years as they are today.
Suppose I tell the carpenter that time is of the essence, I need to clean my garage tomorrow, and I need these shelves done by the end of the day. If they know that they can't deliver quality work in that time, the carpenter should tell me I simply can't have it by then (perhaps suggesting a smaller set of shelves if they can build it with the necessary quality, i.e. scope-reduction).
If the carpenter has any kind of reputation to uphold, they will not risk it on giving me shoddy work, even if I tell them I won't hire them unless I get the shelves today. They know that, when the shelves fall apart, they will still get the blame and be on the hook for fixing them, even though they "warned me" about the quality tradeoff. They know that, if they have to defend themselves from a bad review later by saying "I told them the tradeoffs, and they insisted on quick and shoddy", it's going to sound like defensive whining and won't help their reputation.
If I come home and find that they've spent a lot of time crafting beautiful, artistic joins in a technique that doesn't actually add any structural value (and I didn't tell them I wanted that for some reason) I won't be best pleased. They know that, and so--even if they really enjoy exercising the skill to create that type of join--they won't do it on this project. They might, however, show me a sample and tell me they could do built-ins in my sitting room. If those shelves in the garage seem well-made and don't require a lot of maintenance…
So, for me, it comes down to one thing:
Sometimes, no matter how badly someone wants or needs something, they just can not have it. Period.
Our industry seems not to be mature enough to understand that. We try too hard to please people who don't understand what they're asking for and what the implications are. We cave. We deliver shoddy work. And then we blame the client for rushing us when it is our responsibility to not be rushed. There's always more work than time to do it (thank goodness!) so the size of the backlog is absolutely never an excuse to speed through it by delivering less than your best possible work product.
John Wilger
Phillip Kerman
a hi-jack... I mean, it's just a discussion anyway). Anyway, I do believe
it's okay (on occasion) to do shoddy work. In fact, the fatal flaw from
many programmers is premature optimization. If you optimize some part that
is never being used then all that great architecture isn't worth the effort.
Plus, I've purchased things knowing clearly they wouldn't last. Often it
ends up costing more than I had planned but sometimes I'm perfectly happy
(especially considering the money savings). Take these crappy $30 sneakers
I have on--they DEFINITELY last more than 25% of the time the $120 version
do. I tend to agree it's USUALLY better to make things right to begin
with... but (and code included) it's okay to rush when it's appropriate. In
fact, whenever I fix bugs for a client (and have to charge them) I just
figure the project took less time to begin with. (And, please don't anyone
think there's such a thing as code without bugs. I mean, I did do one
project that had 6 weeks of offshore testing and it's as solid as anything
I've ever done--but at what expense? And, still, there are bugs--pretty
much only bugs we know about, but still.)
I've definitely seen and been guilty of over engineering code. It's an
interesting balance.
As for good code--I'm fairly new to the JavaScript world and find it
interesting to see how few or undeveloped conventions there are. Everyone
is trying to come up with best practices but it's all over the place right
now. I'm pretty clueless where Ruby stands in this area--do you think there
are many widely accepted conventions?
Thanks,
Phillip
Paul Jungwirth
I saw your post to the pdxruby list about finding a passionate Rails
developer. I'd be interested in helping you with Rails work. I was the
CTO and technical co-founder for ElectNext.com (DreamIt Fall 2011),
and now I'm doing software consulting. I'm a full-stack, polyglot
developer with a deep appreciation of the business side and a love of
startups. My approach to development is practical: I believe in
delivering top quality while getting things done. I have eleven years
experience building websites professionally. These days, most of my
work is in Rails and jQuery: I'm equally happy wrangling complex data
on the server side and creating amazing UI/UX in the browser. I'm also
developing an expertise building automated data analysis tools, such
as a Bayesian classifier we used at ElectNext to infer candidate
positions from multiple large datasets. I'm sure I could make a great
contribution to your team.
Right now I'm living in Philadelphia, but my wife and I are both from
the West Coast, and we are moving to Portland in May. I've done a lot
of remote work before, collaborating with widely distributed teams,
but I will also be local within a month or less.
I'm not looking for an employee position, but if you'd like my help as
a contractor, I'd be delighted to work with you. 20-30 hours a week
sounds about right. I've attached my resume and listed some samples of
my work below. My rate is $100/hour. Please let me know if you're
interested!
Thanks,
Paul Jungwirth
http://illuminatedcomputing.com/
https://github.com/pjungwir
http://electnext.com/
http://illuminatedcomputing.com/apartment-helper
http://dollarology.net/state-tax
http://ownafide.com/ (in progress)
> --
> You received this message because you are subscribed to the Google Groups
> "pdxruby" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pdxruby/-/-s4cty3ACKEJ.
> To post to this group, send email to pdx...@googlegroups.com.
> To unsubscribe from this group, send email to
> pdxruby+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pdxruby?hl=en.
--
_________________________________
Pulchritudo splendor veritatis.
Paul Jungwirth
Paul
Kerri Miller
John Wilger
Funny how it's never quite as embarrassing to only reply to the sender
by mistake.
--
Regards,
John Wilger
Paul Jungwirth
lurking on the pdxruby list for probably four months now. My family
and I are moving to Portland in the next few weeks (my wife will be
there looking at apartments next week), so hopefully I'll meet you all
soon at a Brigade event!
Yours,
Paul
km
On Monday, April 23, 2012 2:04:52 PM UTC-7, km wrote:
Hello brigaders!Anyone want to join our team and work on an exciting real estate web app? We're a pleasant, peaceful bunch located in the pearl off of 13th right across from Widen and Kennedy, and hoping to find a Rails developer who is used to writing good clean code, isn't scared to back it up with unit tests, and views developing software as an craft rather then a profession. Git is our versioning system of choice, so knowing your way around git and github is a definite plus. The app is looking to go live in the next month or so, but we believe in releasing early, and releasing often, so there will be plenty of new features for you to lend your expertise, and even specific "programing passions" into. Initially we were thinking of needing around 20-30 hours per week, but if you need a full time gig, let us know and we can see what we can do. Send us your resume, a link to your portfolio or some work, and a cover letter. my email