edw519

28 ms·

211.
by edw519 11y ago
Disclaimer: Twice your age and just getting warmed up. So I'm being let go Congratulations. Being let go can sometimes be a badge of honor. Anyone who has never been let go has never pushed the envelope enough. After 10 years at my
212.
by edw519 11y ago
I never cared about my own "interview performance". But I always cared about my interviewer's assessment of me. So much so that I've always reserved the last 10 minutes of every interview just to find that out. They almo
213.
by edw519 11y ago
I'm old enough to remember when the milkman delivered glass bottles of milk into a box at our back door and picked up the previous week's empties. I remember reading once that the average milk bottle had a life span of 38 round tr
214.
by edw519 11y ago
OP claims: Too Long; Didn’t Learn Maintaining legacy code is boring. Copy/pasting is boring. Internal tools are usually boring. Being a code-monkey is boring. The day-to-day always gets boring. These things are usually
215.
by edw519 11y ago
(Please keep on posting and don't disappear like the good posters of yesteryear (edw519, grellas, etc)) Thanks, Andrew. I didn't disappear. Just spending more time building and less time posting.
216.
by edw519 11y ago
Disagree completely. There are simply too many things that you learn in the interview that are too difficult to learn any other way. Having someone code is NOT about seeing what kind of code they produce (well maybe a little); it's abo
217.
by edw519 11y ago
Most people don't grok that (IBM).1960s+1970s = (Apple+Microsoft+Google+Dell+OpenSource).today for many reasons, but mostly because of the 360 Series, upon which I and many my age got started. I don't miss the COBOL ENVIRONMENT DI
218.
by edw519 11y ago
A few observations from someone in the "Top 10" for 8 years now: - You're never as good as your upvotes. - You're never as bad as your downvotes. - Karma ebbs & flows with the audience, which changes dramatic
219.
by edw519 11y ago
I still haven't found anything that made it so easy for a regular person to become a better essayist, in volume or quality, than Posterous and its auto email feature. Boy, how I miss it. I'm a lazy programmer who would love to blo
220.
by edw519 11y ago
60+, programming for 44 years, triumphed over adversity more times than I can recall, wimpy looking nerd discounted by almost everyone I ever met. Hardly ever got the girl, got to be on the team, got the part, or got the job. I'm a pro
221.
by edw519 11y ago
Technology 1. Know your apps. 2. Understand your domain. 3. Understand your technology under the hood. 4. Have an idea of how you'd approach each project. 5. Write detailed technical specs for juniors. 6. Write general te
222.
by edw519 11y ago
Their risk taking is relentless and they take failure in their stride. Their risk taking is also very well managed because they're shipping dog food. Almost everything that we techies see as innovative is really a byproduct of thei
223.
by edw519 11y ago
Permission to quote requested. Absolutely.
224.
by edw519 11y ago
Excellent site! Congratulations! The only site I ever visit while I work. Whenever I get stuck on something (multiple times per day), I take a lichess break. If I win, I feel better and get back to work. I never lose because as soon as the
225.
by edw519 11y ago
"Miles Per Gallon" is poor metric for reducing consumption. "Gallons Per Year" would be much better. Move closer to work, carpool, take public transport, ride a bike, work remotely. Benefits from these things would dwarf
226.
by edw519 11y ago
Assessing talent is a predictable scientific process. Good companies know how to do it. Other companies don't, so they use contract to perm to compensate. I have hired hundreds of programmers and have never been disappointed. The recru
227.
by edw519 11y ago
Contract to perm is the best way by far. For whom? It's bad for the worker because you're going to work for a company that is admitting by its behavior that it has little confidence in its abiliity to assess talent. Where else i
228.
by edw519 11y ago
Here is what I think about this... ============================= | X | | | | Would you mind taking a | | survey to give feedback | | about this Hacker News | | commen
229.
by edw519 11y ago
Reminds my of the first program I ever wrote, in 10th grade, painstakingly assembled one IBM card at a time, output onto green bar paper. I changed the school motto from "Gateway High School, Hats Off to Thee" to "Gateway Hig
230.
by edw519 11y ago
The trick is to pick the right sorts of projects for the top of the list. The ideal sorts of things have two characteristics, First, they seem to have clear deadlines (but really don’t). Second, they seem awfully important (but really aren
231.
The Upside of a Downturn in Silicon Valley(nytimes.com)
101 points by edw519 11y ago|26 comments
232.
by edw519 11y ago
First: ...young lawyers are less concerned with right and wrong than with chasing dollars. then: But matching people who need help to lawyers who have the time and institutional resources to take on these projects pro bono isn't eas
233.
The Typeface That Turns Everyone into an Instant Speed Reader(eyeondesign.aiga.org)
2 points by edw519 11y ago|0 comments
234.
by edw519 11y ago
1. Decouple dev from analysis; work on only 1. 2. Analysis at night with pencil & paper. 3. Don't go to sleep without specific morning plan. 4. Dev starts first thing in the morning. 5. Always focus on WHAT to bui
235.
by edw519 11y ago
Nice guy whose been contributing here on Hacker News for years: https://news.ycombinator.com/user?id=Peroni
236.
by edw519 11y ago
1. Work on something that you MUST get done. 2. Plan your day the night before. 3. Wake up early and start working immediately. 4. Other people's "obstacles" are your opportunities to invent. 5. One day at a
237.
by edw519 11y ago
you need to start finding customers or new employment in a hurry What I'm suggesting is being the first to present a believeable plan to solve someone else's problem. You're right, finding them and figuring out what they ne
238.
by edw519 11y ago
Here's the dirty little secret about "employability" you hardly ever read about in places like HN: It's not about you. It's about your user and what they accomplish with the tools you build for them. It doesn't
239.
by edw519 11y ago
databasic https://en.wikipedia.org/wiki/List_of_BASIC_dialects
240.
by edw519 11y ago
My story: 1976 to 1985: COBOL (hell) 1985 to 1999: BASIC (joy) 1999 to now: BASIC + Javascript (turbojoy) When I encounter something I can't easily build with my current toolset, I'll look for the "new BASIC"

More ›