I don't know much about Rails, but how easy do you think this would end up being once you can no longer depend on the layers of magic Rails gives you? I know some Sinatra and that's my general impression. It's also pretty obvious when I'm looking at a non-Ruby system built by a Ruby programmer.

IRT to debugging, I have 3 basic techniques:

1- I can read stack traces very well. I hear that's strange.

2- Well-placed print statements.

3- stuff like this:

I do other things, but those serve me very well for a jumping off point.

but isnt print or console.log the same as putting a breakpoint there and checking the debugger?

tbh, I used to consolelog stuff but now I just look at the ide since I can see the value at a particular point and then step thru and track from there.

Had fun yesterday trying to get rid of build warnings in some R Shiny code. Shiny doesn't let you see what's going on with the UI; what events are being triggered. The program was mostly Reactive; changing a variable triggered code watching those variables. You can't inspect Reactive variables during debugging without adding code to unpack them. You can't add print statements to most of the Reactive code because it impacts the value of the variable. A combination of print statements and breaks and stack traces where the errors were and the google where all you had. Fun but frustrating. You could probably figure it out through code inspection, but you'd have to know Shiny more than I or the data scientist who wrote this thing did. Had one section bit of reactive code get triggered 3 times during initial drawing of the UI.

Sort of but not really. You can usually get more info from the debugger and you can do more ad-hoc analysis, i.e. decide what you want to look at once you get to the breakpoint.

Also not every language is as good about being able to serialize objects and log them, the way, say, javascript is.

It was such a rush when finally nailing down a bug that only occurred on disk in a release build. Always started with that feeling of despair just knowing that this was going to be the one to cause the team to miss a deadline - then always ended with a brief moment feeling like a firefighter carrying out a kitten or something. In between there might have been a... few hours of maddeningly staring at disassembled code.

Like goofy mentioned, multiplayer debugging was a special kind of fun as well. Thankfully we never relied on reproducing player input on remote machines. Although objects that serialized/deserialized themselves created a plethora of potential bugs if the gameplay people didn't familiarize themselves with the MP systems. I always enjoyed the networking side of games work though.

Some languages with a REPL can lead you to think a print is displaying the correct answer, but in reality, the entire system needs to be reloaded. This usually happens with an error that the interpreter glossed over when you were programming.

Then there is PL / SQL, which doesn't have a print statement at all*, and is it's own special kind of hell.

* slightly wrong, but tables don't print.

At work I have a text document called howto.txt. In there I write down the solution for every problem that I've encountered and had to ask someone at work how to fix. I did this cause I didn't want to be the guy that kept asking people to help with a problem that they'd already explained how to fix.

Literally the first line in the document reads: "Have you checked the logs?"

First thing I had to learn was "What does the error message say?"

I admit I am sometimes kind of a dick about it but I don't accept bug reports in the form of "such and such doesn't work." Take 2 seconds of your day to compose your thoughts, dudes.

I'm attempting to do an estimate on some contract that wants me to do more work for them. I haven't really tried to do a flat rate with anyone.

I make it a habit to respond to emails within a few hours at most, and my initial thought was "maybe Y hours" and responded as such, but said I'm not too comfortable with that, and didn't offer an $X.

After sleeping on it, and recalling how things went a bit over my estimates before (I was working hourly, but still), and that I never saw this part of the system, I decided that I should add 50% to Y hours and send over a flat rate proposal reflecting the new estimate. This would give me more $X / hr if I finish in Y hours, but if I hit a horrifying situation (this is a near certainty), I may end up a bit below my desired hourly, and that's the risk I'm willing to accept to a degree. I sent them a new $X with a suggestion that I'd be done in Y time.

They wrote back asking what gives about the number. I explained the same thing as above and told them if they are more comfortable going on the prior hourly, then that's okay, but if I go flat rate, I have to bake in some level of risk. I could possibly end up below what they were paying me before and have to consider that.

It's a strange situation. I'm completely not sure if it would make a difference with hourly or flat rate here. I don't think there is much of an upside to going flat rate outside the okay-ish possibility the $X / hr will be a touch higher. Am I going about this the wrong way?

There are very few situations where I've been willing to do flat rate. I can think of 2 times. Once I was just very confident that I could get it done in the quoted time and the other I was trying to drum up business. I probably wouldn't do it again.

There's no upside for you unless you can pad it enough to be sure that you'll finish under time. They wouldn't want to pay you a fixed amount unless they're pretty sure you'll go over on time.

Typically with contract work I do a fixed minimum with a per hour charge. Like say, $150/hour, minimum contract of 5 hours. So if I finish in 2 hours, or 3 hours or 5 hours, you pay $750. Every hour over that you add $150/hour.

"Not reproducible, ticket closed"

don't care/won't fix

It's how the message gets changed from devs to end users...

Had a great conversation with one of my close friends dad's about this once. He owns a commercial fit-up business that gets serious work doing interiors of buildings.

What we agreed on was that fixed-peice works when you are the smartest person in the room. You know the job, the tools, and have probably done exactly it many times before. In that case, you can go fixed price and go for an awesome margin.

In other times of less certainty it is better to go with hourly, but it still ultimately depends on your risk tolerance. In times where you can't afford to lose, hourly is the only option.

I've identified a design pattern in my code and need some wisdom on if it's good/bad.

In our app, there are many places where we show the user a modal. So far, they have all been based on the results of an api call.

I'm sending the request, .then fire an action to the reducer to set a Boolean based on the results of the call. Then, using componentWillReceiveProps to grab the object out of nextProps, and if it's true, popping the modal, and on close firing an action to the reducer to set it to false and close the modal.

It seems intuitive to make calls, set booleans, and pop modals. Is this the right way to be doing this?

I've worked with this company before. It happens to be a system that only two people know how to do anything with: me and the creator. The company knows that. I'm charging considerably less than the numbers tossed around here, but give me the thought that I'm just starting all of this and don't know how to navigate the waters yet.

I'm giving them an estimate based on what I think is the worst-case for me, where if I do worst-case, I'm taking a bit of a loss on hourly. I tossed that flat rate out so they have something for their client. It isn't a huge difference between hourly and flat-rate unless I really get in a jam.

It's also, in part, that I'm over-worked and busy with life stuff at the moment and I don't want to watch the clock. I'll be burning midnight oil if I take this on.

It's just a very junior engineer. I wish there was a good way to test debugging and bug fixing talent in interviews because they are very good indicators of experienced engineers.

so there is a boolean in state that dictates if the modal should appear?

I did an interview once where someone had me do a code review in real time with them. It was all code inspection though, no other stuff that I would call "debugging". It would be fun (for me, as an interviewer) to do debugging with someone but possibly somewhat cruel.

Yea

Seems like an easy process question to ask during the interview.

This is my entire process for finding every bit of work I've ever had. I had no experience at first and possibly no useful purpose today.

Loki peers from many corners.

Yes, but I'm not a fan of process type questions. Easy for people to talk their way into a job. I'd much rather see what they can do, and it's not practical or not possible to do an actual real world bug with a candidates. This is why I still think coding questions are the best way to evaluate candidates because they are forced to work on unfamiliar problems. People are very good at talking about what they already know but at least at my company you're we care much more about their ability to learn and adapt to new stacks and technologies all the time.

I've never really thought about this before, but couldn't you come up with a small program that's not too complex, has a bug, then give it to someone as a code test sort of problem and tell them to find the problem and fix it?