Hacker News new | past | comments | ask | show | jobs | submit | deangiberson's comments login

What do you value more right now? Time or money?


"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience."

Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.

Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.


> I've met many veterans that couldn't think outside the small specialty they had become locked into.

It's the difference between 10 years of experience, and 1 year of experience repeated 10 times


I too have found this assumption to not always be the case. At my company there are certainly some people who qualify as vets yet insist on writing purely procedural C style code and have yet to adopt modern paradigms like OO design simply because they are so far removed from their education.


To be fair, they might be on to something. I've programmed my whole life in OO and recently started looking into FP. I can see the veterans thinking that OO is a fad after seeing things like BeanFactoryFactoryFactory (I personally do not program in Java and have never encountered the use case for a "Factory", and as such do not know what the use case is). After that, what value do you get to adding the functions to structs? I personally see the value, but I also see the value in not doing that. I would recommend teaching them OO while yourself should study FP and criticisms of OO. After them, it may be easier to evaluate which is better for your use case. It sounds like the vets have already cornered you out of OO, but you also definitely don't want to force the wrong tool onto a project just because it's the tool you understand best.


This makes me think of that study[1] about doctors being away on conferences. I think it likely comes down to recognizing that experience rarely, if ever, trumps solid analytical thinking.

[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...


I have a 1yr old System76 Galago UltraPro. I like it, works well, fairly quiet. Purchasing experience was good, even with importing to Canada. My two problems are 1) it will occasionally (once every 2 months) experience a power loss and reset the laptop. No clue as to what's happening, so infrequent that I don't care to look too deep, 2) the wrist rest finish is rubbing off in the corners, looks dirty, but it's just the black plastic showing through.


Anecdote: a colleague bought a system 76 and hated the keyboard, returned it. It wasn't an issue with where the keys were placed, he just didn't like the way the keyboard itself felt, or the way it made him feel, or something.

Try to fondle one before just buying one blindly online.


Their keyboards are notorious for being just plain defective. The issue with the Ultrapro was that it would randomly drop keystrokes if you tried typing at a decent rate. Some people might not have had this issue, but it was nearing epidemic proportions when this laptop was released. They released an "improved" keyboard which was really just the same one with a metal strip on the back of it which made it feel like less of a piece of shit, but didn't really solve the problem.

I wanted to support system76, but their laptops are re-branded clevos, and clevos almost universally have shitty build quality.


yes i had the same issue. I highly recommend not buying System76 unless they have improved significantly in last 12 months. I was bitten so bad by their keyboard issue that I wrote a whole post on it. http://yashchandra.com/2014/05/06/do-not-buy-system76-develo...


I'd focus on a repeating theme in your post, "and now they". This suggests that you already see a division between the management of the company and yourself. You haven't been part of the decision making process and feel that all possible angles have been locked out by an outside agency. How much feedback have you given to the company management that you would be interested in those positions before they where "taken" from you? Have you done a gap analysis between your current operating skill set and the expectations for those position? What skills have you tried to improve outside of "developer" recently that would show you are trying to expand your role?

You need to get past the "been told", and start communicating what you want to achieve. It might be too late at this company, but I would bet not, just because these roles are already filled doesn't mean they will stay filled, or that tasks won't outgrow the current holder. Think ahead, and aim for a goal, communicate with every means you have that your ready for that goal.

"Fortune favors the prepared mind." - Louis Pasteur


Sure, but I think this is just normal as a company grows.

When the company is tiny, you have a ton of hats. As the company grows, those hats become too big for you to wear all of them, and so you ("they") hire some people to take some of those hats from you.

As a developer, if you don't have clear aspirations toward management, usually you go nowhere: your influence erodes until you end up "just another developer", regardless of your tenure in the company.

If you do want to keep doing development, then you need to push management (early on) to create a technical track that's parallel to the management track. There should be technical positions (that come with no direct reports) that are at the same level (both prestige and pay) as manager, director, VP, etc. They need to be well defined, and it should be clear how it's expected that a developer will progress to those levels.

So what I'm saying is that I don't think the OP's real problem is that he has fewer roles, but just that, as the company has grown, he's remained a "leaf node" in the org chart, which just gets deeper as time goes on. If you think about the management hierarchy as your own hierarchy, that's just naturally going to happen. If you have parallel tracks, it stings a bit less.

Or, the OP is basically just built to work at small companies, and he should plan on joining a company when it's small, and then hopping to another small company when it gets too large. That's a perfectly valid strategy, too.


That sounds good too, but aren't you presupposing that this course of things is normal. The OP is saying things turned out differently than expected, and such dissonance really bugs him. Why would he work harder to communicate when working hard has failed so poorly in the past?

Second and third world people probably have similar problems too.


In my experience, what other people thought you communicated and what you thought communicated are often very far apart. Its an amazing thing, Humans are so good at communication but also so bad. I know with my significant other multiple times we have both got upset with each other for actions/inaction that we thought we had communicated with the other, when either we hadnt or hadnt clearly. We have been together for 10 years, and it still happens.

Communication is possibly the hardest thing to get right between two people, because it seems so effortless.



Don't even try communicating with a group of 100 of these so called people; surely three of them will found a religion based on misunderstanding your point, especially if you are the OP.


They can't explain what they've learned, because SICP covers so much ground. The best way I can explain is by negative examples. SICP is not:

- A learn X in 7 days book

- A technique driven solution book (cookbook)

- A quick overview of the new hotness library/language/api/framework

- A list of all the functions that you should know

- A reprinting of the half complete wiki documentation of a weekend github toy

- A one off read that you dump in the recycle bin

SICP gives grounding to some of the core problems in computer science. I've returned to it several times, and I always learn something from what I've missed before. Understanding how functions/closures/namespaces/objects all interrelate, how to think in recursion, building higher order programs from pieces, it even covers simple examples of VMs. It's a very strong entry text that has stood the test of time, and is still providing value. Few texts in comp-sci can say the same. SICP does a good job of connecting the theory of comp-sci with a real language without overwhelming the student with absurd language syntax problems.

When any one asks me to recommend a computer book I recommend SICP. Best of all no one has to take my word for it, the book is free. https://mitpress.mit.edu/sicp/ go read it and form an opinion.

Who is SICP not for? If you are at a high level with programming with multiple languages under your belt, most of this would seem like a refresher. If you really "know" VMs then this is going to very low level stuff. If you want a quick read to learn the syntax for scheme this is not the book for you.


I think these are two overlapping non-linear functions, the intersection of the two is a minima.

"Many eyes" worked for a while but the benefits were lost as scale increased. You are saying that we need to focus on reducing code size. This other extreme is many small unrelated pieces of small functionality, which also breaks down. You would just have a bunch of small programs, some of which are ignored. The complexity remains constant.

Software inspection has shown to have good benefits, this is the heart of "many eyes", the trick is getting coverage. "Many eyes" worked when applied against small enough problems for self organizing groups. As you hint when you say "Modern code is too voluminous for there to be enough eyes to keep Raymond's theory working in practice." Isn't this a management issue? A problem of getting enough people to look into the dark corners and communicate the results?


I was a game developer for various AAA studios for many years and did many, many interviews for new hires. The number one thing that companies will look for is knowledge (you will be tested on this) the next is drive (you have to show that the company should take a chance on you). These things are no different than any other job.

Luckily there is a very simple thing you can do to hone the first and show the second. Make a game. Don't piddle around with an engine, don't read and talk about how you could do this and that if you were given a chance. Make a game. Make it small and completable. There is not a single thing stopping you from just making a game.

Find a genre you like and make a clone, then extend one area with a new idea. Or a clone that show you understand a specific technical area. Or create a mod for an existing game, hack new functionality into Minecraft, or change a control scheme in Half-Life. Just make something you can show, then show it.

A point though, you will find it easier if you pick an area to specialize in. Saying you want to get into the games industry is like saying you want to play in a band. What instrument do you play?

Most game studios don't hire many generalists without experience. So pick one area that you are willing to work at for 3-5 years and double-down. Then find a way to show 1) you've done your homework at a base level 2) are willing to sit-down and do the work.


Sometimes not continuing is the correct way to finish a project. Only keep working on the gems. Fail early, fail fast, fail cheap.


+1 for strong editing features. All the fancy stuff came after Emacs became an OS for editing text. Nail that, the rest follows.


And here I'm going to point to Bret's later writing, http://worrydream.com/#!/LearnableProgramming. It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture.

    for ( var i = 1; i < 16; i++) {
        var br = 255 - ((Math.random() * 96) | 0);
        for ( var y = 0; y < 16 * 3; y++) {
            for ( var x = 0; x < 16; x++) {

                ...

            }
        }
    }
If this was a first introduction to programming it would scare off many people.

My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.


yes - that is also my interpretation - you mouse over the canvas, and the block of code that "lead" to the bit that you "highlight" in the canvas lights up so can directly navigate from the final output back to the source code (and vice versa).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: