This gallery contains 1 photo.
Originally posted on Everything I Never Told You:
The self always strikes dissonant chords, the world of her mind never quite at peace. More often, the self walks along imagination’s street. Here she is free from monotony and fear. The self wants? What? A freezing shot of clarity? The pulse and throb of a sexy…
What is the toughest coding question that you faced in an interview? by @ardit33
Answer by Ardit Bajraktari:
You have 3 hours to build a game of "battleship", and give a presentation of it (both the game, and the code) to the rest of the team.
Extra nice features: online play, nice looking ui, etc.
A proper multi-player battleship game takes a lot more time than that. It is a question that forces you to do compromises and decide on what the MVP is going to be. Also it forces you to adjust what is important, and throw away features/things that you don't have to have during the development, once you realize how much you can complete during that time with your ongoing pace.
It is also a question that reveals how good can an engineer keep their composure when under pressure: do they build proper data structures, nice logic/presentation separation, or do they just spaghetti code the whole thing?
While you can learn 'puzzle style' questions, and find shortcuts to them, there is no way an engineer can fake through something like this.
Which programming language is/was the prettiest and/or most readable? by @mpjme
Answer by Mattias Petter Johansson:
I dislikefor other reasons, but it's very pretty:
# Assignment: number = 42 opposite = true # Conditions: number = -42 if opposite # Functions: square = (x) -> x * x # Arrays: list = [1, 2, 3, 4, 5] # Objects: math = root: Math.sqrt square: square cube: (x) -> x * square x # Splats: race = (winner, runners...) -> print winner, runners # Existence: alert "I knew it!" if elvis? # Array comprehensions: cubes = (math.cube num for num in list)
Follow me if you're interested in this kind of stuff.
What are the most common lies told by programmers? by Martin Katz
Answer by Martin Katz:
Many of the answers you see here are management lies, not programmer lies. Prototypes are proof of concept and/or skeletons of a part of a program. Managers have been known to ship proof of concept as product – they usually are not looking at the long-term picture. The same thing with sloppy/hacky/elite/untested code.
On average, programmers under estimate the work by a factor of 2, because they forget about testing/QA. If there is no detailed design, that can be a factor of 3. Good managers know about this and correct for it (they keep track of expected versus actual delivery for each programmer and can get better estimates after two or three tasks).
Good development requires spending a lot of time studying what the user wants and needs. This includes the format and environment for the program (for example, under Microsoft Windows, disconnecting from the network without logging out and then logging back in will complicate any program immensely). The needs should be negotiated with the client. This should be fleshed-out to include screen appearance and response to user actions under various conditions (Analysis) and a specification provided that the user can understand (and negotiate). A design should be developed that converts the specification to procedures or functions with secific parameters and well documented activity. Tests should be developed for each item in the design (based on the design) before implementation of the procedure or function. Tests should always be written by a person different from the person who writes the implementation (often each will have a different understanding of what the procedure is supposed to do).
When a manager asks a programmer to implement something without a clear connection back through the design and analysis, there is usually insufficient information for the programmer to get the solution right the first time. The manager expects the programmer to write tests and test the code without enough information, and nobody to check the tests. Without suffiicient initial information, the repairs can take several times longer than writing the code in the first place.
Because of poor communication and/or management style, the program seems to be 80% or 90% complete when 80% of the work still remains. Only poor managers allow release of software without tests and documentation (and most programmers do not push back when the manager attempts to rush things). The other side of this is that most programmers do not like writing tests or documentation.
How is Go used at Google? by @rlove
Answer by Robert Love:
I'm hard pressed to beat Rob Pike's talk, which covers exactly this question directly from the mouth of the expert.
is also a great talk. It covers moving our download system from C++ to Go.
Go is designed specifically as a systems programming language for large, distributed systems and highly-scalable network servers. In that vein, it replacesand in 's software stack. Many teams are looking at building new servers in Go; some are even considering migrating existing codebases. Some of the Google technology you use everyday has components written in Go.
I view Go as a general-purpose replacement for C++ for systems tasks, but where it shines most is building highly-scalable I/O systems. The use of Go Routines and Channels can replace 100s and even 1000s of lines of C++ managing threads, callbacks, and state machines with 10s of lines. It really is a nice language for such tasks.