Weird. I wonder if this is playing on the notion that top programmers are all prima donnas / aspie *******s?

Victor lives in Northern Ohio. Expect a heavy dose of sarcasm, gallows humor, and balls of yarn built around wooden paranoia. Overly nice people tend to be suspects, the nice neighbor next door that, when exposed as a serial killer, everyone says "I knew there was something off about that guy!"

well, "yelling" was hyperbole, more "have words with a slight edge toward chewing out"

The thing is, it's not like they're even paying me. I found out it's basically free government money. So, they may be complete idiots, but they can figure out how to fill out a free government money application at the least

Getting free government money for bull**** tech projects with $10/hr employees is basically the stealing money from handicapped people of the tech world.

Unless you have very good constructive advice that is immediately actionable but more importantly executable with the resources you currently have, with the necessary leadership, which I doubt you have. Then any chewing of him out is going to be seen as little more than malcontent from someone deeply unsatisfied with the environment he has for them.

People and companies are about getting things done over certain timelines, and based on how recently you started, you will be effectively ending yours.

Instead, put your effort and energy into finding a better job immediately. It will be worth exponentially more value to you now and in the future.

The job so far has been "sit in chair and do thing" all day. Is this standard for programming? I'm not sure what I expected for entry-level, but I assumed some amount of, I dunno, taking time to learn things, moving occasionally, what have you. I basically sit in a chair and take no breaks for 9-10 hours straight. No breathers, just go to go. This is mostly due to the boss being an incredible micro-manager.

Unless I am really in the zone I usually get up and take a walk or something at least every couple of hours.

Do you get lunch breaks? Does your boss have a technical background? Please don't tell me you are the only programmer here.

The micromanagement is lame but these jobs are pretty much all "work on stories", you'll never get time to "learn things".. that doesn't make them money or look like it makes them money. Enjoy!

yes and no, i mostly work through them. Yes to a technical background, but using very old-school techniques. Most of our work is updating my boss's old work.

Haha.

But really we hust have a culture that promotes respect. I suppose this can be frustrating if another person is off the rails wrong. I haven't experienced this as everyone I've interacted with has been competent.

I've probably already related this anecdote here, but here goes again.

In my first job, I worked with a guy who was pretty smart/good and we got along pretty well. We had very different ideas about certain things in programming, the kind of stuff that flame wars are made of. I don't remember any specifics now, but, say, something like tabs vs spaces. Something where it's very clear to each party what the right way is, and you can't even imagine someone taking the opposite stance, yet, there they are.

Anyway, I left that job and went to another one for a few years. Later I came back, and we found that both of us had reversed our opinions on a few of these issues.

That's when I realized that people can have these huge gulfs between them on certain issues, where neither of them are "right". I started thinking of things in terms of "this is my preferred way to do this, but there are 2 or 3 other ways that are OK" instead of "this is the right way and if you don't agree let's you and me fight"

Yeah but there's still only one correct way to pronounce gif.

No this is not standard. I personally move multiple times per hour. You are supposed to get up every 15 minutes ideally. Usually I don't hit that but it is rare I am sitting for 30 minutes at time. I also take at least 30 minutes for lunch. I was at an internship where I was there from 11 am to midnight or 1 but I took breaks whenever I wanted, and would take about 1.5 hour break to go for a run and then get dinner.

Eww sitting in a chair for 10 hours straight. That is so bad for your health. Just get up and say you have to go to the bathroom, get a drink of water. I still don't think yelling is necessary but definitely stand up for yourself.

Any good links WRT software testing? Like just general conceptual stuff on writing them, incorporating into workflow, etc. Language insensitive. I have a lot of improving to do in this area.

PM/Skype chats are also very welcome

I don't have any recommendations on what to read, but my basic philosophy is that any new feature starts with *at least* a basic set of tests. I will typically write a very naive set to start, i.e. one or two pass cases and one or two fail cases. I'll run these and then write code, rinse and repeat until the fail ones fail and the pass ones pass. After that I will typically run through in my head all the things that can go wrong. I will stub these out, i.e. write a bunch of tests with no bodies, where the function names describe the test.

It is not uncommon that I will release the feature at this point, because usually someone else is waiting on it. While they try it out I'll start fleshing out the tests.

When at all possible I try to make anything that the test relies upon abstractable. For example, if the test needs 2 users to exist before it starts, then I want a create_user() function or a User() fixture or something like that. Avoid going directly to functions that create a user, or worse, straight to the database, because this ties your test to your current implementation and makes change difficult.

It is sometimes tempting to take shortcuts in your test, such as using code to construct, for example, error response messages. The problem is that it becomes easy for your test and your code to make the same error. As painful as it is, make your test asserts as explicit as possible.

Something that I think a lot of people **** up is that they write a test and assume that since their code passes everything is fine. Sometimes you will make a test that doesn't actually test what you think it does. For every success test you write, you should introduce temporarily an error that *should* make the test fail. Once you're satisfied, "fix" the bug you introduced.

Anything that breaks in prod (or that breaks while someone is trying out your code) should get a test case, because clearly it exposes a weakness you did not test for. The fix isn't ready until your code passes this new test.

Code coverage is important but not the end all be all. It is a necessary but not significant condition: without high coverage, your code is not well tested, but 100% coverage != everything is well tested.

If you don't have time to write good tests, such as when you are starting to work on a legacy project with little or no testing (as I am), start by writing "tests" that at least *execute* as many of the functions in your project as possible. This will help ensure that, if nothing else, all the functions in your code base *can be run*. It'll help expose problems that you'll create yourself while making changes, such as getting rid of a needed function, or library or changing the function signature that something else is using, etc. (This is mostly a problem in dynamic languages)

have some assignments due next week for a c++ course. they have videos you need to watch for how to get set up. The videos do not load.

Inspect in chrome shows me the problem, which I'm sure you've already guessed:



far be it from me to question a school's methods, but if you're teaching CS and still using that technology, I'm instantly suspect about the quality of the education I'm going to receive from you.

someone should make a site/service that is basically bootcamps on a smaller scale. Like, say I really want to learn whatever tech suzzer's familiar with. He can agree to mentor me for x months in exchange for y% of my first year's income when I have or get a job. He can do assignments, code reviews, help me assemble a portfolio, etc and I can get individual attention, learn what I want to, and possibly make industry contacts.

good idea? terrible? let's just call it uber for bootcamps

Terrible idea. The two big benefits of a bootcamp as I see it are having a focused curriculum tailored to becoming immediately employable, and a strong network to help you land a job - both of which would be missing in your idea. What you want is a tutor.

Rusty,

Seems like collecting a % of some possibly non-contiguous year of salary is a gigantic PITA. So many weird loopholes and edge cases.

I think a better strategy might be if a company just guarantees me X-amount, then they can come after you forever if you don't pay. Obviously they'd want a huge cut for this. But it still might be worth it for me and you. I paid progressively more for each poker coach and each one was totally worth it.

Well then there's the whole thing if you're not satisfied blah blah. A lot of ways this deal can go bad. Maybe I get a chunk up front, and then a chunk every month as long as you stay satisfied. If you're not satisfied you can walk away at that point. That could work. PM me

This is true, but that does not mean his idea is not worthwhile. The major tweak is changing the compensation structure from percentage of salary to fee based or some combination.

There are massive benefits to building up a community of trusted providers for anything and I don't see how this would be any different.

In other words, sign me up. Let's get started today noodle! Übercamps or ubootcamps?

Hm, I feel like I have a friend who kinda of does this. Let me see.

Well, their site is down and looking around it might be more of a traditional bootcamp. For some reason I had assumed it was one on one via the internet

I think we can agree that the most important thing is coming up with a clever, catchy, and trusty sounding name.