Hot answers tagged

182

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


110

As far as I understand, pipe is a system call which shares a piece of memory between two processes where one process writes and other reads from. Actually, there is no shared memory involved. The reader and writer are NOT sharing any part of their address space, and they are not using any explicit synchronization. The reading and writing processes are ...


43

Yes but with a lot of care! Let me clarify that. You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to ...


36

You should log every change you make to your system. There's nothing wrong with logging it after the event - as long as you link the bug report to the change number. Then if anything ever goes wrong you can track back to the bug and find out why you made the change you did. In the vast majority of cases you are right and no one will look at these ever ...


27

Most places I have worked the QA people do have some sort of sign-off step, but do not have final authority on if the release proceeds or not. Their sign-off represents that they completed the testing expected by the release plan, not that the release is flawless. Ultimately QA != the business and the business needs to decide if they are OK with deploying ...


26

Google uses a shared Google Docs document between the interviewer and candidate while talking over the phone. They share the document, which is preset to a fixed-width font, to the candidate in advance with the confirmation email. A Bluetooth headset or speakerphone is recommended for hands-free coding during the phone interview.


20

Yes You can. BUT... You have to be careful. At the begining of my career (very long time ago) I was lucky/unlucky to get into a few months old project as the "Junior". As the first thing I noticed, there was (OMG) no code repository! All merges of code were done manually by sending zip files to each other by mail. So I went to my (also new) manager and ...


19

It's a common mistake to think that Scrum is equal to Agile. Being Agile is following the four principles of the Agile Manifesto. Scrum is a project management process consistent with those principles but it's not, in and of itself, being Agile. XP (TDD, pair programming) is a development process, also consistent with those principles, and consistent with ...


19

The main reason is the cloud. It used to be that your code got shipped on floppy disk, and then CD, and then it got deployed to a server, and then it got deployed to two servers (for resiliency)... And all of that deployment could be manually done by a human, so humans were trained in doing it. Today, your code is often going to dozens or hundreds of ...


15

There are lots of different reasons for various organisations to move to DevOps. I'll try to list the ones that come up often. Reduce time to change cycle There is often a long time between making a request for change and it actually being deployed and used in the organisation. First it is planned in one of the development cycles by the developers and after ...


15

Short Answer Should I fix the code myself? No. Should I give them feedback on the review process and let them do the fixes according to my instructions? Yes. According to your suggestions, not instructions. Instructions sound too authoritative. And if so, how do I give this feedback, do I fill certain template document and send it to them, or ...


14

If you use a source control tool, then you can describe the bug you fixed in the commit description and that is usually sufficient documentation for super-small, trivial bug fixes. Furthermore, if you use a bug/feature tracker that is fully integrated with your source control and repositories, like FogBugz and Kiln, you'll be able to use the global search ...


14

This is a somewhat tricky and even complex question, in a sense that you can go quite deep with this. But to simplify things a bit: Considering your example of "reading the timer in a game of mines": First step is to find the memory address. This is usually done with a tool called memory editor(a debugger would do too, in some cases) which can use various ...


14

In my opinion, the genius of the idea of "pipes" is the simplicity of use. You don't have to make any system calls, allocate memory, nothing complicated at all. In the shell, you use a single character: |. This gives extraordinary power in the combination of simple (or complex) tools to a given task. Take some common everyday tasks like sorting text ...


14

Is it worth a (junior) developer's effort to try and push for the above as time goes on? Yes, it is always worth your effort to try and make things better. You know best what problems you face after all. But as you mention, there are lots of problems to solve and many of those problems are not terribly valuable. And at a lot of places, there will be ...


12

Yes. But organizational change is hard even for a senior so if you really want to make a difference do it in the right way: Not during the first weeks: Use this time to: Create a good first impresion. Show that you fit in the team. Understantand the culture and politics or your company. Is it safe to push for changes? Build a good relationship with ...


11

Collabedit is also a nice platform for online coding interviews. It offers real time view of what the candidate is coding, as well as a feature to chat. It can also do syntax highlighting. an online code editor that lets people collaborate in real-time. It works in your web browser so no installation is needed... Features text editor ...


11

A few advantages for each off the top of my head. Note that some of these items may not apply in all cases; these are just general observations. Sockets Simple and controlled. Can be extended to network sockets as necessary with little or no modification. Programming model requires serialization, which in turn requires you to think about what data actually ...


11

Have you looked in a dictionary? The word thread has a meaning past sewing. 3: something continuous or drawn out: as a: a line of reasoning or train of thought that connects the parts in a sequence (as of ideas or events) http://www.merriam-webster.com/dictionary/thread


10

Mathematically, the problem you describe is to find an unknown function f with y_i= f(x_i) (i=1,...n) for a given set of input values x_1, x_2, ... and corresponding output values y_1, y_2, ... To answer such questions, you will typically have to make some assumptions about your function f. For example, if you assume f is a linear function of the form ...


9

Ever seen how multiples threads, twisted, form a thicker, stronger cord ? That's the metaphor, every thread is independent but all threads together collaborate to a final computational output. Besides, as in the textile thread, a thread can break without compromising the structure of the whole cord.


9

Yes. But not the things you suggest. Out of your list Unit/Integration tests are the only item you can make progress on. You can start adding these by yourself with minimal time investment and show instant value. Its a technical problem with widely accepted benefits and wont affect others work practices. While also gaining you mdore knowledge of the code ...


8

Yes, one-to-ones are very important, above and beyond the meetings Scrum dictates. Daily standups give daily feedback on the state of the project. Iteration planning meetings are specifically for planning the next iteration. Even retrospectives concern what we as a team are doing well or can do better. Nothing in Scrum encourages a manager to sit down, ...


8

The second example you gave is certainly not a traditional User Story, which is generally formulated something like As a *role*, I want *goal/desire* so that *benefit*, but is what I would call 'acceptance criteria'. According to the Wikipedia article linked above: Every user story must at some point have one or more acceptance tests attached, ...


7

Need to save some state Put it in the database Retrieve on next login Actually, when the user logs in again, what you'll need to do is figure out how many pieces of iron ore should have been mined while the user was gone, and update the database with that knowledge the next time the user logs in. If other users interact with the "pieces of ore" ...


7

"Is this right that little endian processors read the memory addresses from highest to the lowest address and where as a big endian processors suppose to read them from lowest to the highest address?" No, that would just be an implementation detail of the memory chip, which would not make any difference for how you use the system. In the little endian ...


7

tl;dr: They're called threads because "thread" is an apt metaphor. When you start a thread, you rely on the operating system to allocate processing time so that your thread can execute. While your thread is executing, the processor (or core) is placing all of its attention on your thread. When the operating system switches the core to a different thread, ...


7

Although there is no single source of truth about these terms, I think we can agree about the fundamental difference between a program and a process: a program is a set of instructions intended to achieve a goal. It is an artifact. Instructions may be expressed in a human readable high level language or an equivalent low level (compiled) machine ...


7

There is no single standard software development process with clear defined responsibility for everything: On one side this is unfortunately, because it makes life harder. You have to organize everything in every project and agree on roles and responsibilities. If software is build for a customer, this could be part of the contract. And it will not ...


7

One solution is to adopt the "LTS" (Long Term Support) model used by Linux and browser vendors. At the end of a sprint, if you have a version fit for release, you create a release. Give it a version number, label it in git (or whatever version control you are using, but I'm assuming git here), update the docs etc. You then effectively deploy that release ...


Only top voted, non community-wiki answers of a minimum length are eligible