Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment The Toxic manager (Score 1) 140

I'm not sure why but they are missing the Toxic manager in there.
I used to have a manager that would ensure that whoever he nominates to be the lead on a project would fail to accomplish most, if anything in the project.
First very unrealistic time tables for the project, which was essentially a rewrite of an existing CMS from scratch. 3 months.
He booked easily 60% of my time in various meetings. Spent a lot of the rest of the time planning and designing features to "stay ahead of the curve".
Of course during that time I still had to make sure that the legacy systems still worked.
Then pulls me aside to say that "my" team feels that its weird that I am not programming on the rewrite.
And of course, keep changing who is on the project team to ensure complete discontinuity.

Then came the low performance review and this is when I realised how much of a shaft was waiting for me. I quickly transferred to another team within the company and a recruiter thankfully called my cell phone shortly after.

Essentially the manager I had stayed in place because the team was responsible for generating most of the revenue for the business and he always had someone to preassign the blame.

2 years after I resigned he was made the lead of a new team. Those team members refused to work with him within the first month. HR eventually wisened up and looked at the part performance reviews and exit interviews that targeted that manager, he was demoted and told that he can keep working in his corner until he can find a job at another company.

The major lesson I learned is to never tolerate a bad manager. As soon as you can, leave.

Comment Leave, and don't look back (Score 1) 433

Its the same as when you have a supervisor that cannot be trusted or that sets you up to fail so that he looks good.
I left his team for another team within the company, thankfully that was relatively easy. This allowed me to gather my wits around me and a few months later I left for a much better job at a company that actually listens to their developers.

In the exit interview I made it abundantly clear that I left because of the bad supervisor, and I also took the time to praise the new one in the other team.
I learned through the grapevine that the bad supervisor was eventually assigned a whole new team to start a new project. A few weeks in, they _all_ refused to keep working with him. Eventually HR reviewed his file and realize the toxicity he brought with himself. He got reassigned to a "special project team" and made it clear to him he won't be doing anything else until he left.

Comment Tried both, handwritten all the way (Score 1) 192

In the late 90s, I decided to do some A/B testing to see which method worked best for myself. I had 6 classes for a term, 3 of them I took handwritten notes, and 3 of them I took typed notes.

I've never been much of a crammer and usually relied on rereading the notes once or twice prior to an exam.
After the midterms, I've noticed that I had a higher score for all 3 classes with handwritten notes, so the next thing I did was to ditch the laptop.
One thing I love about handwritten notes is that I can visualize myself having written them and found that it helps recall the information. On the laptop, it was much harder.

Even with classes where the teach provided typed out notes (or printed out powerpoint slides), I would continue to write my own notes in a big binder of loose sheets.

Classes are there for learning, not to transcribe what the teacher says.

Even now at work, I use pen and paper at meetings. Laptops and computers just get in the way and provide way too many distractions.

Comment Amateur level fail (Score 4, Interesting) 85

"The Honeywell Tuxedo Touch Controller web interface uses JavaScript to check for client authentication and redirect unauthorized users to a login page."

You'd think that a company like Honeywell would know better about security, especially as they have a whole cyber security division...
This is like the pages that had a crappy javascript password which you could read by seeing view source, if you knew the keyboard shortcut (right click would be blocked on javascript).

Mistakes an amateur would make.

Comment Re:Who uses virt floppy anymore (Score 3, Informative) 95

From the article:

Floppy drives are outdated, so why are these products still vulnerable?
For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

Comment Good communication (Score 1) 261

A good work environment is one where people trust you and you trust them. Trust comes from communication. And I mean the clear communication that has a clear objective and purpose, not the management buzzword bingos that fill in meeting time.
Everything ends up tying back to good and positive communication.

Some insights:

- Setup an IRC chat. We tried many other group chat systems before, and we always come back to IRC. Choice of clients help as everyone will have their preference. There are also a lot of bots that can help also make it a more central communication hub. We have it with both our monitoring software and our build system. This help cut down on the noisy chatter in a dev area.

- Make sure that accomplishments are visible to the rest of the company. (If you follow real Agile/Scrum, that's your sprint review). This will help avoid the "cost center" label that brings underfunding.

- See if you can accomodate hardware/software requests. It makes no sense denying a well paid programmer a 200$ ram upgrade that can speed up his work.

- Bad news will happen. Your job will be to deal with it and to bat for your team. Don't throw them or a team member under the bus.

- Make sure the rest of the company communicates with your before going to bother your team. If need be, get a Scrum Master.

- You'll probably read a lot about offices vs open areas vs cubes. Cubes are a sucky halfway system. Open areas is better for communication but introduce distractions. Offices cut down on distractions but tend to create silos of knowledge. The best I've seen is an open area with offices available for meetings. If possible, get an open area that is not shared with non team members.

- Break down silos. Avoid having specific team members always working on the same system or module in the code. Its true that work will get done quicker by having the silo, however if when something breaks and that person is unavailable, its going to be much harder to fix it.

- Reviews: If the only focus of HR with the reviews is to have a paper trail when someone needs to be de-hired, they will always suck. Done properly, they are tools that can help your team members grow. You can ask your team member to fill out the form in a self-evaluation way, then have a meeting with them to see how their view of themselves compare to yours.

- Breaks are important. Be it coffee, lunch, paid break, evenings, weekends. They matter.

- Overtime only works for about 2 weeks, after that, the productivity level goes back down to pre overtime rates. There are numerous studies on this that have been published.

- Make sure that your team has all the tools needed to do proper QA. If your production environment is load balanced, then the QA must be load balanced.

- Whiteboards should be easily accessible, with plenty of fresh markers. At least have 2 more then the size of the team plus you. Whiteboard paint isn't so good as its much harder to clean to do the orange peel effect.

- Team lunches are nice, get some budget for them.

- If need be, fire the bad apple in the team. If someone is always disruptive, produces low quality code, keep messing up, is rude, you need to let them go. It sucks and its a very hard thing to do.

Agile / Scrum:
If you follow it this is critical:
- Do not skip the retrospective. This is critical as that is the way the team will improve.
- Make sure that all changes to a sprint go through the PO. The PO will need to remove the equivalent amount of work from the sprint. Ensure this happens.
- Internally, plan a buffer of time for miscileanous improvements. Let the team decide and take charge of that time. Do not let additions to a sprint chew up that time.


Comment Re:First and foremost (Score 5, Interesting) 176

Also look at oursources payroll, time tracking (this is sometimes a must for R&D tax credit) and make sure you have some financing / funding lined up. You need to have a plan to cover the first 2 years of operations where revenue will be slim.
This will also allow you to avoid getting into the "anything for a buck" mentality.

Don't focus on development tools / standards. Let your programmers take care of that. You might want to look for a lead developer with experience managing junior / intermediate developers.

Comment Re:Help! Help! (Score 1) 865

There is also no "bugless" mechanical system for that matter. Mechanical throttles have gotten stuck, brakes can fail, especially if they are poorly maintained. Poor maintenance usually kills mechanical systems, poor practice and poor programming create bugs. However software that is written will always behave in a definite pattern. Mechanical system will fail differently with different effects.

The systems:
- Switch to neutral or reverse
- Parking brake
- Brake override
- Push button quick presses
- Push button long press
- Speed limiter

If NONE of the system works, then I'd have to concentrate on not crashing for about 30 to 60 minutes, then the battery will run out. I'd crank the heat and open the windows to increase energy usage and drag to speed up the process.

If there is a passenger, they might be able to pull the emergency fuse plug from the rear seat floor.

Comment Re:Help! Help! (Score 1) 865

Nissan supports both long press and push multiple times (3 times I think).

I've had the Nissan push button since 2009 and love it. No fuss, no issue, always started / turned on the first time.

On the Leaf it will also shift to Neutral if I press the park button while in Drive.
Worst comes to worst, it wouldn't take too long to drain the battery pack if all else fails.

Comment Re:The answer, in short, is "NO" (Score 2) 716

Also the building companies know how much time is required to build a wall and every step of the way is time budgeted. If you wait too long to put the next brick on the mortal, it would be too dry and won't hold the brick. If you don't mix the mortar components long enough, then it might not hold up properly. Also the end product is very well known in advance (eg size, mortar color, brick colar, rows of bricks, etc). The customer agrees to the wall on paper before the work starts and can't go back saying "that is not what I meant when I said 5' high, its too high now and I don't like it " and expect it to be fixed for free. Each job is uniquely done for a specific customer to that customer's specs. Customer also tend to understand it that there is a certain way to do it.

The problem often times with software is that there is pressure to cut costs (less people, less time), cut time to delivery, cut tools, change requirements all the time, etc. The builders of software are rarely listened when it comes time to fix problems. Technical debt accumulates with every change that is done on a temporary basis just to satisfy the customer quickly.

Going back to the analogy, no one would ask a builder once the wall is built that brick at position 5,10 is not the right shade of color, change it now. Yet we expect this from software all the time. If builders would change all the bricks in a wall it would most likely fail.

Comment Re:Last about five years? (Score 5, Interesting) 237

My experience tends to mirror Backblaze, both with my own personnal business and as an employee at 2 different companies.

Seagates would always fail prematurely, but usually in a way that is noticeable through SMART monitoring. Interestingly it matches up with when they acquired Maxtor, which also started going bad when they bought Quantum. With my colocated servers for my side business I used to have to go at least twice a month to replace a failed drive. I eventually gave up on Seagate and replaced all but 1 drive (a spare raid member) with a mix of WD and Hitachi. I'm also really pissed at Seagate to have slipped so much in reliability, especially with their 7200.11 and early 7200.12 drives.

WD would fail sometimes, near when they were new. Where I worked previously, we had a policy of mixing new and old WD drives in a new server. It was a lenghty process but helped avoid losing a simple RAID1 setup.

Hitachi very good and usually inexpensive.

Where I'm working now we're trying out Toshiba and so far one drive failed out of 12, but that sample size is way too small and its not been long enough to truly tell how it will go.

Slashdot Top Deals

panic: kernel trap (ignored)