More info here if you want to see how regions are structured at a high level of detail: https://youtu.be/AyOAjFNPAbA?t=15m21s

I used the J-Link but I wanted to do it on Linux, so I used the JLink GDB Server along with the GDB build that comes with the Arduino IDE. It probably takes me a good 5 minutes to get everything set up, but the basic stuff works: breakpoints, stack trace, reading and writing memory locations.

The setup is a little convoluted, I'm not sure if there is a better way, but here are my notes:

    Procedure for running w/ debugger attached.
    
    1. disconnect debugger's usb
    2. connect device via usb
    3. arduino IDE program device
    4. identify elf, set up gdb with elf.
    5. plug in debugger
    6. run jlink gdb server
    7. attach gdb to jlink server "target remote:2331"
    8. "monitor reset", "continue" to re-run target from beginning.
    9. observe device is recognized by Arduino IDE
    10. open Arduino IDE serial monitor to interact with device.
    
    Now, Ctrl+C in GDB halts device, and stack etc. can be inspected, and
    then it can continue running with "cont".
    
    To rerun the device with the same program without redoing everything,
    go to step 8 and reset the device. and continue from there.
    
    To find .elf on linux:
    ==================================================
    find /tmp -name sketch_name.ino.elf 2>/dev/null
    

    gdb location:
    ==================================================
    /home/user/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb
    
    
    JLink setup command:
    ==================================================
    JLinkGDBServer -device ATSAMD21G18A -if SWD -speed 4000
    

    gdb attachment:
    ==================================================
    (gdb) target remote:2331

For example, if I'm working on a Python script under 1000 lines I would never use a debugger. I might use wireshark or linux system tools if something was really wrong, but usually the trackback or program output is sufficient.

I've also tried to debug an Arduino project where I had a lot less knowledge of how the system works, and if I wasn't able to attach a debugger I don't want to know how long it would have taken me to find the problem (calling a null function pointer causes an interrupt that didn't have any handler).

I've also tried to debug other people's projects in high level languages, without a debugger where after taking about an hour to figure it out based on pure reason, realizing it would have been very quick and easy to find with a debugger.

I think if you look at what a program is doing, and at that point you can't form a testable hypothesis as to what is happening, at that point a debugger will certainly be faster if you know how to use it.

I think DAG coins could be a lot more efficient, but I'm not totally solid intellectually on how they achieve consensus on conflicting spends so I'm not sure it will work as a general solution. The only one I've used, nano, has I believe no mining reward, and I think consensus is achieved based on a voting process weighted by proof-of-stake among online nodes -- the incentive for participating in the system is that the system has value for you in other ways. I'm not closely following ETH PoS research, but it will be interesting to see what they can accomplish, it could create a huge reduction in energy consumption.

If you're referring to financial markets, I personally learned a lot from Trading and Exchanges: Market Microstructure for Practitioners, although I didn't finish it. But it explains the basic characteristics of financial markets, and why they are set up the way they are. It isn't necessarily going to be obvious and financial markets are based on hundreds of years of accumulated knowledge.

Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).

As an engineer, I want to find the demons that are out there in the problem space and assault them, I want to eliminate all weakness from my precious software. But from the business POV I know we need to provide value to customers quickly and efficiently with the available resources, which is usually not the same thing.

For i.e. the arrow keys, or anything interactive you will probably have to be watching for the response.

For a senior role:

1. Someone who can't write and debug a for-loop and an if-statement isn't going to be able to provide training and support to junior level hires. At all.

2. Making high-level changes and performance improvement both require good process discipline, and the ability to write a lot of code to actually accomplish it.

I think there are high value software management tactics that can be implemented without knowing how to code, for example, change control, or enforcing limits on work in progress via. kanban, but for a role that has either "software" or "developer" I think fizzbuzz is a very low bar.

I personally like binary search as in interview question. The basic principle is simple, but there are enough edge cases and variations to make it interesting.

It seems it will be focused on large scale products out of necessity because of the availability of structured data and public disclosure.

There is one preliminary paper linked in the article, which I haven't read: https://dl.acm.org/citation.cfm?id=3172876

It is really interesting to see ways to establish causality without a randomized controlled trial, since in a lot of circumstances an RCT is impossible or unethical, and because for many decision making purposes you need to evaluate interventions, not just relationships.

(included some other countries to compare, Saudi Arabia is also an interesting one but it messes up the graph.)

- a short trip allows battery needs to not be excessive

- bypass traffic, you don't have to go all that fast to get a huge speedup, and remove the extra buffer time on traffic uncertainty

- radically less infrastructure than roads or rails, reduces the cost of adding more pickup zones

In cites with poor airport to downtown infrastructure you could probably start off as a high-end service and charge i.e. 5x than an airport limo.