TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Give A Damn

132 点作者 10char超过 12 年前

15 条评论

klibertp超过 12 年前
I have different problem - I just can't code like The Kid anymore. I know I could in the past, I have the code to confirm this. Not anymore, I'm not able to.<p>And often I'm required to. My boss says: "just hack it quickly" or "it's one-shot script, just write it" and wants it done in an hour or so. And I can't do this.<p>I don't even know why I can't. I tried many times to "just code" and there's something in my mind that seems to be opposed to this. This "something" refuses to use unknown or not fully understood tools. It refuses to let ugly line of code be. I feel like I'm refactoring my "one-shot" scripts reflexively, without me noticing. And the worst thing is I do it continuosly - not when the script is finished and somehow works, but during writing it for the first time. I know exactly when was the last time I wrote more than twenty (Python) lines of code without breaking the code into functions and classes, caring about names and comments: in 2004. Tests came later, but now they are a reflex too.<p>And now what my boss wants done in an hour I write in three or four. Then he's getting angry and tells me to go clean and document some code or to implement something else, and I do, and it more often than not works and - I hear - could even be a pleasure to read. But then, few days later, he wants me to quickly convert something or export something or something like that and I just can't do it, unless I have previous script ready. Then he's angry again...<p>TL;DR - giving a damn is certainly a good thing, sometimes, but taken to the extreme can disturb your career.
评论 #4707871 未加载
评论 #4707798 未加载
评论 #4707439 未加载
评论 #4707788 未加载
评论 #4707987 未加载
评论 #4707462 未加载
评论 #4708015 未加载
评论 #4707621 未加载
Zarel超过 12 年前
On the other hand, I'm reminded of this passage from HPMoR:<p>"But Father had once told her that the trouble with passing up opportunities was that it was habit-forming. If you told yourself you were waiting for a better opportunity next time, why, next time you'd probably tell yourself the same thing. Father had said that most people spent their whole lives waiting for an opportunity that was good enough, and then they died. Father had said that while seizing opportunities would mean that all sorts of things went wrong, it wasn't nearly as bad as being a hopeless lump. Father had said that after she got into the habit of seizing opportunities, then it was time to start being picky about them."<p>Or, in context: You can't skip directly to writing quality code. First, you have to get used to writing code, and to do that, you have to write a lot of it. You have to get used to getting things done. Only after you have a good grasp of getting things done, of seeing a project to completion, should you start worrying about code quality.<p>I have a lot of unfinished projects, and a lot of smaller projects that I have finished. I'm sure all of us do. But once, I decided not to worry so much and just start writing, and I started and shipped an incredibly ambitious project. It wasn't my best code, but it taught me a lot about not sitting at a blank screen trying to plan everything to be perfect before starting.
评论 #4707196 未加载
评论 #4708004 未加载
DanielRibeiro超过 12 年前
Kent Beck, the guy who created Extreme Programming, Test Driven Development, and the first Unit Test Library ever, made a very similar point about this a few years ago, in his "The Flight of the Startup"[1]<p><i>In the taxi phase, breadth, speed, and, above all, cost of experimentation is the key. Try out ideas related to lots of different needs. Precision of feedback during the taxi phase is less important than trying out lots of different kind of ideas. The risk during the taxi phase is that you won’t find a genuine need. Address this by reducing the cost of experiments and running many of them.</i><p>After working for a while for Facebook (<i>the move fast and break things</i> company) he described how deployment speed dramatically affects how you work on his "Software G Forces: The Effects of Acceleration"[2].<p>So, it is not a secret that <i>discovering</i> "something people want" is more important than working code[4], because failure if the great equalizer of code: all good code and all bad code is equally thrown away[5].<p>[1] <a href="http://www.threeriversinstitute.org/blog/?p=251" rel="nofollow">http://www.threeriversinstitute.org/blog/?p=251</a><p>[2] <a href="http://www.youtube.com/watch?v=KIkUWG5ACFY" rel="nofollow">http://www.youtube.com/watch?v=KIkUWG5ACFY</a> which was seconded by Mary Poppendiek on her "How Cadence Predicts Process"[3]<p>[3] <a href="http://www.leanessays.com/2011/07/how-cadence-determines-process.html" rel="nofollow">http://www.leanessays.com/2011/07/how-cadence-determines-pro...</a><p>[4] <a href="http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Beck+Revises+the+Agile+Manifesto+%28for+startups%29/d056n" rel="nofollow">http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Bec...</a><p>[5] <a href="http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/182318/" rel="nofollow">http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/...</a>
imechura超过 12 年前
I'm gonna go out on a limb and say that this "kid" was not utilized correctly.<p>He had a valuable "1 in a million" skill and instead of finding a way leverage that skill in a new and innovative way the team pigeon holed him into a vanilla software engineer role. Perhaps he should have been responsible for building alpha releases for new customer features, understanding that the more detail-oriented software engineers would come in afterward and make the code production ready.<p>I see these two types in my job every day. One type can put something amazingly valuable out there in no time flat. The other type is meticulously detailed oriented and can perceive every possible permutation of a use case and ensure that the system is coded to handle them. Unfortunately the streams rarely cross, however we expect both types to do the same job due to our close minded view on roles and responsibilities.<p>In short, possibly, it was not the kid who did not "Give a Damn". Instead it was a rigid team who probably did not realize the value he could provide.
评论 #4707720 未加载
greatzebu超过 12 年前
&#62; "Code is more than just a tool," I heard he said. "It's our craft. It's our muscle. And we need to train it. Chop wood. Carry water. Code."<p>I seem to hear this comparison between skilled manual labor (especially carpentry) and coding come up all the time. Yet I never hear writers or mathematicians making that comparison, and I rarely hear engineers or scientists in other disciplines make it. Maybe that's just because I listen more to programmers, but I think there's an actual difference, and I wonder why that is.<p>I also wonder whether or not there's any connection between writing better code and using "best practices" in all your google searches. I suspect not.
评论 #4708569 未加载
评论 #4707794 未加载
jiggy2011超过 12 年前
Did anybody else end up with the voice of the narrator from the game "Bastion" in their head dictating this?<p>I have to say that my standard practice now is to write all my code twice. I write it the first time and just do "whatever" until it appears to work. Then go back and refector, add tests etc.<p>That second time I always find an astonishing number of bugs that I hadn't even considered.
greenyoda超过 12 年前
It sounds like the all too common story of an inexperienced programmer being overwhelmed by technical debt[1] as their code grows larger and more complex. I'm sure it's a lesson that many programmers learn the hard way at some point in their careers (like I did).<p>[1] <a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow">https://en.wikipedia.org/wiki/Technical_debt</a>
afterburner超过 12 年前
I'm sure there's great programmers out there who can do things fast <i>and</i> well, so hopefully people won't be too quick to judge any fast workers because of this story. Tempting to think there's a quality cost to speed; could be the true cost is just a high salary.
joelmichael超过 12 年前
Why not just work out the bugs in his redesign? You said he got it done extremely quickly. It didn't seem like he was presenting it as a final version, but rather as a demo. Instead you throw it all out? How long did the replacement version take to finish? How many people worked on it? Was it feature-complete and free of bugs?<p>This reads like someone getting their spirit broken.
评论 #4708873 未加载
danbmil99超过 12 年前
There is a place in the ecosystem for programmers like this. There are times when a quick demo can have a huge effect on business prospects. The key is to understand that the whole thing needs to be recoded, by engineers who understand process and architecture. Then just put "the kid" on the next flashy demo.
simonbarker87超过 12 年前
I've had a side project on the go for 18 months now and am about to complete the third version. Each time I've started from scratch but the difference is each time I have cared just a bit more about the quality of the code and planned things more in advanced. It's still not perfect (by a long way at that) but if I had't just dived in on the first version I fear I would never have shipped the first version let alone be on to launching the 3 do over. This one, should (fingers crossed) be the one that I stick with, hopefully it is extendable and I actually cared about database design and normalisation this time around so that should work well for a while too.
jyap超过 12 年前
I think that more experienced programmers can achieve the same results as The Kid. In a larger organization, you may have separation of programming roles so you may not have a 'Kid' at your disposal.<p>If you have a method for rapid prototyping or something which allows you to bash out a quick proof of concept. Sometimes management needs that as the visual impact goes a long way to getting projects approved.<p>So long as you then convey to others that there are bigger long term concerns and proper design to look into when making the full version you can take it from there.
elliottkember超过 12 年前
At first I didn't like this story. It sounded too much as though The Kid got stuck in an inappropriate role.<p>But on reflection, it's more interesting. He was doing fine, then his situation changed. So he changed along with it.<p>I think that's what I like most about The Kid. He didn't quit, or blame anybody - he altered himself to better suit his environment.
iopq超过 12 年前
My boss wants me to be The Kid. "The users won't know the difference!" Sure, you can just hack together everything and the users won't know, but at what cost in the long term?
BungleBob超过 12 年前
Lesson 1) The Kid is unemployable Lesson 2) That's why The Kid is The Boss.<p>Be The Kid (or get a job).