Tag Info

Hot answers tagged

46

If all you have is 2 days and no time to prototype or even read upon all the alternatives then there's really only 2 options: ask someone who knows and follow their advice. This may not necessarily mean asking an individual but spend the 2 days searching through blogs and articles to glean enough information to make a slightly-better-than-uninformed ...


41

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


18

A couple of things. Don't assume that your seniors don't know what they're doing. They may have very good reasons why they made the decisions that they did; ask them why (in a non-argumentative way). Code that is already written, backed by unit tests, and declared functionally complete by your superiors can be safely ignored. That's what you should do ...


18

It may seem that I am going against the stream, but I have recently read the book Creativity, Inc. by Ed Catmull and there was a really nice paragraph tackling this situation: Andrew Stanton spoke next. Andrew is fond of saying that people need to be wrong as fast as they can. In a battle, if you're faced with two hills and you're unsure which one to ...


14

Would this be considered as bad, cowboy coding, anti-pattern. Short answer: no. Doing "agile" correctly does not mean "no planning", it does mean not to overanalyse things. one of the major reasons why Agile is used is because clients often change the requirements. That's an oversimplifying statement. "Changing requirements" is also about how the ...


12

@RobertHarvey's comment is dead right: Process will not produce bug-free software, but good process can at least reduce the recurrence of classes of bugs. Sounds like you're attempting to accomplish the latter, so I will make my suggestion of where I think your mistake came in: You failed to account for all the details of your production environment in your ...


12

I recommend the following guidelines: Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself. Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the ...


12

Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times. This might be a good idea if: It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is ...


10

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


9

They are not following MINIMUM coding standards. If it's not your job to police the coding of others, then don't do it. It's a classic way for juniors to make a bad name for themselves. See this question for a similar discussion: How do I tell a senior programmer that I disagree with him Related: A blog post I wrote about disagreeing, and part of ...


9

Throw-away prototyping Throw-away prototyping is about creating, as fast as possible, a part of the future application to either ensure a feature is technically feasible or to show the feature to stakeholders or potential users in order to gather feedback from them. Since the source code of this prototype is not reused later when developing the application ...


9

gbjbaanb makes some very good points. I just thought I'd add a bit. It's obvious you don't have enough time to make a perfectly informed decision. Your only option is to try and make a decision that will minimize future pain. I'd suggest: Clearly document the nature of the situation: Send an email to your manager(s) and CC their managers and the ...


9

I think your summary have over-simplified the blog post somewhat. :p I'm going to pick out three sentences, which I think is crucial as to explaining why code became... lava. The code gen system had somewhat broken down after Bruce had left. None of the remaining team really understood how it worked, so it was easier just to modify the code by hand. ...


8

Don't ask for pseudocode. If your superiors thought you needed that, they would have provided it already. Here's what you should do instead: Make your requirements testable If it's not testable, it's not a requirement; it's a feature or wish. More specifically, each individual requirement should be SMART: Specific Measurable Assignable Realistic ...


6

I've started working with gitlab, reading the HELP section provides a workflow layout. At this point, this seems to be the best solution to my question. If anyone has experience with this workflow or advice, please add any additional info. From the HELP section: Workflow Clone project git clone git@example.com:project-name.git Create branch with your ...


6

One strategy, which can be established with any decent VCS, is to open a parallel maintenance branch in such a situation (based on the latest stable production release) and merge only the immediate bugfixes or other urgent changes for production into it (for example, the changes of your developer B). Typically, you can create a maintenance release from this ...


6

Short answer: No. Longer answer: If your refactorings are truly improvements, then you're engaging in Codependent behaviour - you're supporting your collaborator's bad habits & not giving him/her the opportunity to improve. If your refactorings are trivial, then you're probably wasting your time and/or risking the possibility of falling into an edit ...


5

Using agile in this situation is still a very good idea. There are many benefits to agile, only one of which is regular feedback from the customer and the ability to respond to changing requirements as you mention. One of the main reason waterfall projects are notorious for failure is the 'nearly done' problem - testing produced piles of bugs at the end, ...


5

How to document code? You already have a hint: look at how Java API is documented. More generally, there is no unique set of rules which apply to every project. When I work on business-critical large-scale projects, the documentation has nothing to do with the one I would write for a small open source library, which, in turn, has nothing to do with the ...


5

This sounds weird, the network IO lag would erase most of the benefit of in memory data accessing on individual machine. I would wonder if your approach would even be faster than buying a single machine with lot of SSDs to run as virtual memory, or even machine running on virtual memory using regular HDD. Secondly, you have to redesign your logic before you ...


5

What if I need a tool that could make my daily work much more efficient and there is no alternative? Then talk to your manager about it. Most companies that restrict workstations will also have a policy that allows new tools to be added, if it can be shown that there is good justification for it. It's not that uncommon in larger organizations. Aside ...


5

A good developer's guide should be able to guide developers who want to use your product/library. It should give them an overview of what the product/library is. It should have an overview of any special concepts necessary to use it. For example, if you have a library creates formatted documents of a very specific type, an overview of the document ...


5

Since they've effectively given you little time to do more than pick candidates out of a hat, I'd adopt the following approach. Select technologies that: Have a large user base Have active support (via whatever channels) Are being actively developed By definition, this would rule out any bleeding edge technology, however good it may be. Also, resist ...


5

Yes, but I recommend changing how to go about doing it. Rather than refactoring on your own, do a code review. Work on refactoring and cleaning up the code as a group. You clearly know there are better ways to write the code, so share! Maybe your coworker will learn and start writing better code. In the future, maybe you will not need to spend so much time ...


5

Several ideas. Although I am not very sure how generally applicable they are. First, in a lot of articles that reference this anti-pattern, the first advice is to resist the urge. One way to resist the urge is to understand the Dunning Kruger effect, and to spend time exploring whether the urge to refactor could have been influenced by the lack of ...


5

When releasing a new version of a program is it better to include the full changelog since the beginning of the project or just the part since the last release? Neither. Only provide the relevant, bigger changes that an end user is going to care about. No one cares about the fact that you refactored class Foo so that it can be re-used a bit more ...


4

First-order rough-order-of-magnitude analysis is the first step. It takes (nominally) one instruction to access one word of local memory. Assuming it takes 1000 instructions to format the TCP/IP packet and queue it for transmission, and another 1000 instructions at the far end to receive, dequeue, and interpret it, and realizing that an "access" requires ...


4

There's something called netiquette. When you develop web scrapers you should oblige to these rules. Remember, you're a guest, you're using their server's bandwith (which they pay for) and data (which is of their intellectual property) to your personal profit. They aren't legally bound to give you anything but they can take legal actions against data misuse ...


4

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established ...



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